I have been going over allot of IIS tuning for my web application, and have set everything that I have found online. But I still had some lag after some time idle, even after setting idle time out to 0, and the action to Suspend in the advanced app pool settings. If I also set the CPU Limit to 0, and Limit Interval to 0 - this seems to take care of problem. What would be the drawbacks of doing so, besides no more CPU monitoring. Could this cause other problems? Also it seems strange why if my Limit was 0, and I am experiencing lags on pages left idle, then I set Limit Interval to 0 - problem solved?
Set idle time-out=0 means w3wp.exe keeps running. Disable CPU limit works indicate that recovering from idle still consume CPU usage.
But disable CPU limit is obviously not a good idea, CPU limit protect the operating system from crash. You would rather crash a website but not the entire system. I recommend give it a higher limit.
You can also try to set Start Mode: "always running" in Application pool advance settings to see if it works for you. Another thing to consider is about the session state, which also has an idle time-out configuration. Set a higher value in case this application does a CPU consumption move when lost session state.
At last, you may consider find the reason by using performance profiler in Visual studio.
Related
We are currently using an M2 Large server from Amazon.
In the Advanced Settings of an application pool in IIS 10, we are using these options,
Idle Time-out Action: Suspend
Idle Time-out (minutes): 1
Start Mode: OnDemand
Recycling Time Interval (minutes) : 1740
When the application pool is in suspended mode the next day, the startup of the application is still slow. Could we improve the startup while using these settings?
Your Recycling Time Interval is 1740 minutes or 29 hours. From https://weblogs.asp.net/owscott/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes ,
However, since you likely know your environment, it’s best to change this. I recommend setting to a fixed time like 4:00am if you’re on the East coast of the US, 1:00am on the West coast, or whatever seems to make sense for your audience when you have the least amount of traffic. Setting it to a fixed time each day during low traffic times will minimize the impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools it may be wise to stagger them so that you don’t overload the server with a lot of simultaneous recycles
You would probably have to use application initialization (see https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization) and increase your Idle Time Out as well to make sure your app is hot for the first user.
I'm running a very high traffic site that gets a good 300+ requests/second (http://cooltext.com). A restart takes a good 90 seconds at least for it. So every time I post a new build it goes down for a minute or two. Long enough to trigger my monitoring services.
When I make a change that restarts the server, it appears that the restart stalls until all of the old requests on the old application pool (some of them very long running) complete. I can make the restart happen much faster by killing the old w3wp.exe instance manually.
Is there some way to force IIS to close all the connections right away and do a hard restart? Some setting in IIS or asp.net to control this?
Just found the following that appears to be what I'm looking for: http://msdn.microsoft.com/en-us/library/aa720127(v=vs.71).aspx
Shutdown Time Limit is the equivalent application pool setting for the shutDownTimeout ASP.NET process model setting. It specifies the amount of time a worker process is given to shutdown gracefully. If the worker process does not shutdown in time amount specified, the ASP.NET ISAPI will end the worker process. Shutdown Time Limit is set to 90 seconds by default. You can specify a different time limit by changing the value in the spin box.
I am running IIS6 on Windows 2003 Server 32 bit. I have read that IIS6 has a maximum virtual memory limit of 2gb (3gb with the 3gb switch fipped).
What I am unclear on is whether this means all ASP.NET sessions have 2gb between them or 2gb each.
So if I have a session variable storing 200kb and have 10,000 active sessions am I going to be hitting up against this 2gb limit?
In general the advice is to leave these options unticked for ASP.NET applications, it affects how quickly the appPool recycles more information here summary below:
Physical and Virtual memory: This section is for recycling application pools which consume too much memory. Focusing on physical I typically like to limit app pools around 800MB to 1200 MB max on a 32 bit app with very few app pools depending on the number and amount of memory. On a server with 2 GB RAM I'd set it at around 800MB max. On a 4GB of RAM server around 1GB and more if more with a max around 1200. On a 64 bit web front end with 8-16 GB memory I've heard of settings of 2GB of RAM or even allowing it to let it ride, rather than limiting it.
You really need to profile it since these can really grow to process and cache. The greater the amount of memory and the greater the load the higher the worker process will grow. When people ask about configuring the app pool, this is where they are usually asking what the numbers should be. What you are doing here is explicitly limiting the app pool from consuming more memory.
Notice this setting is on the recycle tab, there's a reason for that. When an app pool reaches the max it isn't like the max processor setting. It will cycle the worker process which is like a tiny reboot or similar to an iisreset, but not since sometimes we want this to happen so we can release our memory. You really don't want to cycle more than a couple of times per 24 hour period in an ideal world. I've heard of some trying to cycle right before the morning peak occurs so they have the most amount of memory available, then a cycle right at the end of the day before the backups or crawling begins.
Basically the recommendation is not setting a limit (leave the options unchecked) because once the limit is hit IIS will recycle the application pool causing all active users to be temporarily disconnected from the site. You users will likely receive an HTTP 500 while the application pool recycles and then once it's back there will be a delay while the application pool warms up.
Sessions
For an application of any size do not use InProc (stored in memory) sessions use state server or SQL server to store your sessions. http://msdn.microsoft.com/en-us/library/ms178586.aspx
Conclusion
It really depends on the profile of your application, if your expecting 10,000 active sessions though don't use InProc, don't use IIS6 and don't use a 32 bit server.
My Asp.net application uses
25-30% of the CPU on a test server which has 600 MB Ram on it.
I can see the asp_wb process taking that much percentage of CPU.
This is when I am testing using one user.
How many users can the server afford then without falling over?
Is there a relationship between the CPU Usage and number of user aka if there are 2 users my application will sky rocket to 60% of memory usage?
Or does/Should/How does the server handle this?
The asp.net is base on pools and not on users.
Some memory per user is going on user session, but I believe that you not hold huge amount of data on sessions (did you ?).
Now I suggest ti run process explorer from sysinternals, and check on w3wp.exe the working set and the virtual size of the memory for this. You can do that by open this 2 columns on Process Memory tab.
Then you see there how many memory asp.net needs for your application.
Second step if to check how you have configure your pool by open it. Maybe you have configure it to recycle too often, or to recycle when you have more than 125k working set memory, and your program have 200k working set memory. So you need to recalibrate some values.
Together with process explorer you can see how much memory your application need, and setup correctly the pool.
Of cource maybe there are other problems and other issues with the memory but asp.net is not eat memory for every user and you need to check where your memory is used - and the process explorer is a good tool for this job.
Hope this help.
After deploying an ASP.Net application to a new server, the first user to hit the app gets a long pause, presumably because the app is performing its initial compilation. However, this pause seems to also also occur after the application has timed out and unloaded itself from memory.
The first compilation would be tolerable as it only happpens once, but the 2nd one seems to me like it should be unnecessary....is there a workaround to address this issue? It would be nice to be able to extend the application timeout, but I only see a way to extend the session timeout, which I would rather not do, as this would keep all user sessions in memory for a long period of time.
That's IIS shutting down the worker process - the default is a 20 min idle time. In IIS6, you can configure the app pool and turn off the Idle timeout (on Performance tab). In IIS7, it's in the Advanced Settings.
A common way (though looks hackish to me) to keep the worker process alive is to have some program issue web requests to some URL in the application on a regular basis.
You can reduce the initial startup time by precompiling the ASP.NET app with aspnet_compiler.exe. This won't reduce the initial request time to zero (it'll still need to create the worker process and do other housekeeping.) but it'll noticeably reduce it.
I did find some recommended settings for the App Pools in IIS. The intended outcome of these settings is to reduce the number of times your application needs to go through the startup cycle. These settings should apply to IIS 6 as well as IIS 7:
Recycle Worker Process: Disable. Use this only if you have multiple websites and are trying to isolate processes.
Shutdown worker processes after being idle for (time in minutes): Disable unless you are sharing resources on your server. With this setting disabled, your website should not unload, ensuring that startup time for your site is as minimal as possible.