Performance degradation over time in Gen 8.6 .NET client/server application
Article ID: 236799
Updated On:
Products
Issue/Introduction
We have a customer that has problems with our Gen 8.6 .NET client/server application regarding the delays on loading the client pages.
Client Window Manager executables built with generation defaults:
OS: CLR,
Language: C#,
TP Monitor: ASP.NET
Server Manager executables built with generation defaults:
OS: CLR,
DBMS: MSSQL,
Language: C#,
TP Monitor: Comp_Services,
Communications: .Net_Remoting
The application starts to slow more as the user navigates from one screen to another in the application.
Our other customers are not reporting the same problem.
Environment
Release : 8.6
Component : Gen Run Time, ASP.NET
Resolution
Reviewing client trace logs collected with web.config having '"cmidebug" value="-1"', showed that calls to the Gen servers were not taking significant time and those times were not increasing.
The problem occurs when using the default Session State value of StateServer (and likely would occur with SQL Server too), but not when using InProc. However using InProc is not feasible because it causes the application to encounter a problem elsewhere with some file handling logic and also Session State data stored in InProc will be lost when the IIS Application Pool/worker process is recycled.
It was found that the customer's model application had been designed with Link dialog flows to go from client PStep to client PStep i.e. PStep1 to PStep2 to PStep3 to PStep4 and then back to PStep1, so the return flow on each of those Link flows was not being used.
Gen Engineering advised that because Link flows are used, Gen will hold onto certain data with the expectation that it will be needed when the Link's return flow is executed. However, in the above workflow, the Link's return flow is never used. Since the Link's return flow is never executed, the amount of data kept will just keep growing and growing resulting in the performance degradation.
As a Transfer flow will clean up data stored for any prior Link flows, the recommended solution is to change the Link flows to Transfer flows.
Alternatively, each Link's Returns On flow could be used. However, from a performance standpoint, the Transfer flows have much less overhead and should always outperform Link flows.
Notes:
1. The above also likely explains why the performance problem is not noticeable when a Session State of InProc is used i.e. every time the IIS worker process is recycled, all the data kept up to that point is lost. Therefore, it never gets to the point where the amount of data kept is large enough for the performance problem to be noticeable.
2. Similarly if other customers aren't following this same exact workflow, then that may be why they are not reporting a performance problem. If they execute a Transfer flow somewhere along the way or they are taking an execution path that actually returns on the Link flow, then they may not be experiencing the growth in the amount of data kept.
Additional questions:
Q1. The first 1 or 2 times when the call from one client to another happens (both at "Link To" and "Transfer To" options), the response times are quite bigger than next times.
A1. The initial executions include dll load times when flow from one PStep to another. In some cases, it can be beneficial to package multiple PSteps together in the same load module. But this is usually only helpful when it is known for sure that the end user will be following a workflow that requires all the PSteps that are packaged together. Otherwise, it might just hurt the initial load time unnecessarily.
Another possible delay could be if the ASPX pages have to be compiled at runtime. This can be avoided by selecting the "Pre-compile ASPX pages" option at Assemble time in the Build Tool (by default it is enabled).
Q2. Also, in the middle of the tries have noticed some sudden peaks at response times, and then go to normal again. Is there a known reason for this? Perhaps, something like garbage collector takes place, or something else?
A2. In Gen Engineering's testing they also witnessed similar spikes, but could not associate the spikes to anything Gen is doing. It may be related to garbage collection, but they believe the most likely cause is the State Server. If these spikes are causing significant problems, the suggestion is to contact Microsoft to see if they can recommend something (e.g. State Server/IIS configuration settings) to help alleviate these spikes.
Additional Information
Feedback
