Investigating Slow Performance on K2 environment

  • 16 February 2021
  • 0 replies
  • 612 views

Userlevel 1
Badge +7

Issue

K2 environment is very slow. Forms are taking much longer time to load and SmartObjects are taking longer to execute.

 

In addition to that, the following warnings are shown in Event Viewer logs on IIS server, which suggest that a K2 application pool has been crashing.

 

A process serving application pool '<K2 app pool name>' suffered a fatal communication error with the Windows Process Activation Service.

 

Restarting the server helps for a while, but the issue always comes back eventually.

 

Investigation Checklist

There are various causes for performance issues. Here is a simple checklist you can run through to help you diagnose the issue.

 

  1. If you only have specific forms that are slow, please refer to this KB on ways you can tweak the performance of your forms.
     
  2. Check if there are process instances that are stuck. Process instance should not stay in running status for too long. You can use the following query on your K2 database to assist you in identifying process instances that are stuck.
     
    SELECT *FROM [Server].[ProcInst]WHERE [Status] = 1ORDER BY [StartDate] ASC

    You need to run this query a few times, at intervals. If you spot a process instance that appears every time you run this query, then it is possible that process instance is stuck. You can try stopping the process instance with K2 Management. if you are unable to stop the process instance with K2 Management, please log a support case with Nintex Support to request for assistance in stopping this process instance.
     
  3. Check server's CPU and memory utilization. If CPU and/or memory utilization is very high, in the 90% to 100% range, find out which process is using up the CPU and memory. If you find other processes (not K2HostServer.exe) that are using up a lot of CPU and memory, see if you can stop them and observe if there are any improvements to your K2 environment.

    You will also want to monitor if the CPU utilization rises and drops with your peak hours. If the CPU and memory utilization rise as your server becomes busy, and drop when your server is idle, then there is a possibility this is a load issue. You may want to consider adding additional servers to your K2 environment to cope with the increased load.
     
  4. Check if you have full HostServer logging and SmartObject logging enabled. These logging options are only used if you are attempting to investigate or debug issues. You should always disable them once you are done with your investigation. Leaving them enabled can affect the performance of your K2 environment.
     
  5. Use IIS Manager to monitor the requests in the K2 application pool's worker processes. This can be accessed by selecting your server in IIS Manager > Worker Processes, and select the K2 application pool. Monitor how many requests the worker process is handling, and see if you can find long running requests by looking at the 'Time Elapsed' value.

    If the requests keep piling up, and there are requests with very huge time elapsed value, then that is an indication that the worker process is receiving requests faster than it can process them. If the requests keep piling up, the worker process will likely crash eventually, which in turn will crash your application pool.

    Take note of the requests that have huge time elapsed value. If these requests are for AjaxCall.ashx, then it is likely they are SmartObject executions. SmartObject executions have to go through your K2 server, so if such requests have huge time elapsed value, this may indicate your K2 server is a bottleneck.
     
  6. If your K2 application pool is crashing, you can setup DebugDiag to collect crash dumps of your application pool. You can send the dump to Nintex Support if you need assistance analyzing the dumps.
     
  7. If your K2 service is still running when the performance issue is occurring, you can use DebugDiag to collect a memory dump of K2HostServer.exe. Send the dump to Nintex Support so that they can check if there are anything in the dump that can explain the performance issue.

Additional Information

 


0 replies

Be the first to reply!

Reply