The tech brief that Stefan attached, and the links it points to are very good points for everything performance. Plus the documents in the Qlik Scalability group (some produced by the same people).
They discuss the topics of working sets (which is a concept of Windows OS rather than QlikView). In general, you don't need to change those unless you have problems.
The object calculation limit depends on at least 2 factors:
- Performance (I): if the limit is too high, one single user could potentially exhaust, for a few seconds, the resources of the server. That's why, there must be a limit, especially if the server is used by dozens of people. If an object is too complex, the developers of the app will need to take a closer look and see how to make it lighter.
- User Experience - Timeouts (Performance II): in Ajax, when an object takes too long to calculate or it's complex, it does not print on the script an error message, most of the time you see "Reconnecting...". You may want to adjust that value if your QVWs have complex objects.
If you are not experiencing either of the above, leave the limit as it is (I tend to think if the previous admin did it, there was a reason). Anyway, think that 60 seconds is a long time in general, speaking of QlikView, to wait until an object is rendered, so probably you don't want to increase that number unless you expect your users waiting for an object to be displayed for over 6 minutes.
And needless to say, just ask. Most things involving performance are not easy and they don't have a handbook, they involve QlikView but also Windows and hardware, and also, because the applications you develop and the applications I develop are completely different, aiming a different audience and using a different infrastructure. There are good practices, of course, and most of those you can find in the group linked above.
.png "Miguel_Angel_Baeyens"){kind=avatar}
