Article ID 1158 Article Title INFO: Session Limit Encountered When Running WebApp Server Article URL http://www.dataaccess.com/kbasepublic/KBPrint.asp?ArticleID=1158 KBase Category _DAW INTERNAL INFO Date Created 10/05/2000 Last Edit Date 10/07/2016
We did some stress testing on a new Web Server. We used the 'Web Application Stress Tool' (WAST) from Microsoft to simulate a number of concurrent sessions.
The server was a fast server with lots of RAM and a fast SCSI disk drive. The server was hooked up to our local net through a fast connection. We did a number of tests requesting the Home page of our server without following the links on the homepage to images, etc. to put the load on the ASP part of the server. We asked WAST to simulate 160 (4 threads serving 40 requests) during 2 minutes. What we found is that if you let the WebApp Server Service communicate with the desktop, it loads much more concurrent sessions!
Setting 'Interact with desktop' to false would give us about 35-40 concurrent sessions. Setting 'Interact with desktop' to true would give us about 120 concurrent sessions.
Is this something you guys have seen before or would have an explanation for?
We set the performance indicator to give the highest priority to the background process.
Yes, this is a known issue. We've seen this. It has to do with interactive vs. non-interactive desktops. There's a Registry setting you can change so that a non-interactive desktop can create just as many windows as the interactive desktop.
The registry setting is in:
Watch out for Session Manager, there usually also is a key called SessionManager (notice no space), it's the one with the space we are talking about.
In that key you'll find a setting called Windows. This is the one to edit. It's a long string with many settings, look for something that looks like this "SharedSection=1024,3072,512".
The 1024 part is according to MS a legacy setting that's no longer used. The 3072 part is according to MS the heap size reserved to the interactive desktop. The 512 part is the heap size reserved to all other non-interactive desktops. The latter is the one we want to change. So, just change the ",512" to ",3072". Then click OK, and remember to reboot the machine. The change will not take affect until you reboot the machine.
- The specific default settings may be different from platform to platform and that the example above is just that, an example. Serious web sites needing a good expected load test. Simulate your peak loads and see how the server responds in a number of areas (memory usage, overall performance, optimal server settings for process pooling, enough non-interactive desktop heap, etc.) and you'll see if changing this setting is one of the steps needed to "right size" the environment.
- Increasing this setting increases the number of processes that can be run simultaneously. If you use Process Pooling, the server will be able to handle far more sessions with fewer processes, to a point that the heap size value you have set might never really become an issue.
Chris Hibbert reports that the number of sessions depends on the size of the compiled WebApp program (WebApp.vd?):
This is happening for us with way lower than 33 sessions. We hit it as low as 11 sessions on a live app today, accompanied by "failure to initialise Comctrl32.dll" - one message per connection attempt, and we had a lot of people connecting! That was resulting in failed DFRUNs accumulating, needing to be manually killed off.
This is not a "33 connections" problem, its a "numconnections*size of .vdf" problem - ie, memory footprint of app - this VDF is 1Meg.
Last week the .VDF was just over 600K, and we were running up to 30 sessions no problem.
The above mentioned value of 512 might be different on other versions of the Windows operating system. We found a default of 768 on a Windows 2008 server. While the number is higher errors or fault situations can still exist.
This article is recommended reading for the following keywords and/or categories:
session limit webapp server
Company: Data Access Worldwide
Web Site: http://www.dataaccess.com
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2024 Data Access Corporation. All rights reserved.
The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.