Diagnosing slow system response

The following scenario explores approaches to analyzing slow system response for apps and reload tasks. This condition might be identified on the 24-Hour Summary or Performance History sheets if there is a very high average server CPU usage or on the Task Reloads sheet if average load duration time goes up significantly. Neither of these indicators are necessarily definitive. The changes shown might be normal variations, such as a series of reload tasks that normally run longer. Another indication might be that users complain that their system response time is unusually slow. The Operations Monitor can then be then be used to diagnose the problem.

When slow system response appears to be a problem, the steps below offer one analytical path that might lead to a diagnosis.

Do the following:

1. Switch to the 24-Hour Summary sheet in the Operations Monitor app.
2. Review the Qlik SenseServer CPU chart to see if there is high average usage for an extended time during the 24-hour period. High CPU usage could indicate a hardware problem, or it could be a symptom of problems or conditions elsewhere on the server, such as reload failures, system errors, or increased usage.
3. Review the Qlik SenseServer RAM chart to see if memory usage is unusually high. Memory usage of 90% or above should be considered high. Average RAM and maximum RAM usage are usually quite similar over a 24-hour period.
4. If memory usage is high during some part of the 24-hour period, check the Summary table to see if average RAM is higher for the 24-hour period compared to the 7-day and 28-day periods. Higher current RAM usage could indicate that something unusual is occurring and could be causing the slow system problems.
5. Review the Proxy Connections chart to see if there is a high number of active connections from the client.
6. Check the Active Users chart to see the number of users is high during the period when response has been slow.
7. If the number of users is high, switch to the Apps & Users sheet to see if there is a correlation between the number of user sessions and the period of slow response.
8. Select the time period in which the slowdown occurs and review the Session by Hour of Day and Session Duration Breakdown charts to see if there is a large number of sessions or sessions that last a long time. Sessions with long duration times could be running apps that are very active (many selections), perhaps a meeting presentation or deep analysis. It is also possible that a session was left open without ongoing activity in the app, or an app got stuck or did not close properly. Usually a "frozen" session does not consume a lot of resources. Long session duration could be caused by users accessing apps during long meetings or doing extended analysis.
9. Review the App Session Summary chart to see if there are specific apps running in a number of sessions. It is possible that one user has an app open in multiple browsers but is only actively using it in one place.
10. Check the Individual Session Details to see if there are sessions or apps in which users are making a large number of selections. A large number of selections requires more work by the Qlik Sense Engine Service, which could slow the system down, especially if there are multiple apps in which a large number of selections are being made. If there are multiple apps with no selections, they could be idle or stuck but consuming resources.
11. Switch to the Task Reloads sheet and select the date or dates for which slow system response is occurring to see if there is an extraordinarily large number of reloads being performed during the period or if there is a large number of reload failures occurring.
12. Check the Reload Duration chart to see if the average duration is high during the slow response period.
13. Check the Task Statistics table to see how many reload tasks have high average durations and how many reload attempts those tasks have made.If there are one or two apps reloading data frequently and whose reloads take a long time, you might have to move those app reloads to another server or reduce the number of reload tasks to free up CPU time for other apps that are negatively affected.
14. Check the Failed or Aborted column in the Task Statistics table to see if the apps that have long average reload durations are failing frequently. Reload tasks that are failing frequently could be experiencing connection problems with their data source and are left in a wait state for long periods, or they are being rerun immediately after failures. Problems with the reload tasks might have to be fixed to reduce load that is slowing system performance. The most recent data load execution logs are available in Qlik\Sense\Log\Script and are listed in the app GUID.
15. Check the Task Execution Details table to see if tasks that fail have long durations or if they take a long time to run successfully.If the reload tasks run a long time and then fail, the problems with the task will have to be fixed to improve system performance. If the tasks take a long time to run successfully, they may have to be moved to a system with more resources to prevent them from blocking other apps.
16. Switch to the Errors & Warnings sheet to see the types of errors and warnings generated during the slow response time.If the errors are concentrated in one or two services, or perhaps one or two types of errors recur many times, then you can see whether one of the services has to be fixed or perhaps a particular type of error will point to a problem with a reload task that can addressed.

There are multiple issues that could cause poor system response time, and the preceding review of the Operations Monitor objects could reveal one or more problems that are affecting your systems.