In an ASP.NET website we are storing sessions in SQL Server. All is working fine except that sessions frequently recycle. I've a timeout period set to 30 minutes but some times it recycles within a few minutes. We've a dedicated server, and website running under a 'classic' application pool. I've searched a lot on this problem, but didn't find a satisfactory answer. Any help will be greatly appreciated.
Note: mostly it happens on a page where there is lots of use of viewstate, I'm curious that is there a link of viewstate with session recycling?
We've experienced this problem when we either have a web farm (more than one web server servicing clients) or a web garden (more than one worker process in an application pool).
If you have a web farm, then you need to ensure that all web servers have the same machine key and that all instances have the exact same application path.
If you have a web garden, try dropping the maximum worker processes back to 1 to see if that resolves the issue.
While you are checking the IIS settings, you should probably also ensure that the application pool is not recycling regularly. This can be due any of the following specified in the app pool:
1) Private Memory Limit (the app pool is reset if the maximum amount of memory has been exceeded)
2) Regular Time Interval recycling (the app pool is automatically recycled after a specified number of minutes, defaulting to 1740, and/or at specific times).
3) Idle Time-out (the number of minutes of inactivity that can elapse before the application pool is automatically shutdown).
You should also check the event logs for reports of the application pool crashing or otherwise being recycled.
Update:
An additional thought:
If you have an application, such as anti-virus or backup software, that monitors your application's bin directory and modifies or changes attributes (such as the backup flag or timestamp) of files in that directory OR your web.config file, this will cause application recycling as well.
Related
I have two Application Pools, Prod_Apps_Pool and Prod_Mobs_Pool. For some reason, the Prod_Apps_Pool will keep stopping, but the Prod_Mobs_Pool will keep running just fine. I do understand that it's the Rapid-Fail Protection that is turning off the pool; what I don't understand is what failing specific process is causing this.
Looking at Event Viewer, I do get a System Error that says "Application pool 'Prod_Apps_Pool' is being automatically disabled due to a series of failures in the process(es) serving that application pool." Prior to this error, I have several warnings about processes serving the pool exceeding time limits during shut down, as well as processes requesting a recycle due to reaching a virtual memory limit.
I do not see anything in the Application Log, nor anything in the W3SVC# logs IIS logs. If I had to guess, I would say that these processes that are exceeding time limits are counting as "failures", the maximum number of failed processes in a given time limit is being hit, and then the Rapid-Fail Response is being triggered stopping the application pool. I would further guess that one of the applications in the pool specifically is causing these issues.
How can I specifically find out which application is causing this to happen? The only thing I have seen suggested so far is to put every single application in the pool into it's own pool, then find out which pool is shutting it down. But aside from the impracticality of separating a pool with dozens of applications into dozens of separate pools, this still doesn't tell me what error is causing all of this.
What's the best approach to narrow down the application and error causing this?
We have a web application deployed on IIS 7.5 target framework 4.0
the application perform slow when leave idle for few minutes for first time and then perform as expected this happened each time application is idle.
With the help of fiddler I found its TCP/IP connection which is taking time about 21 secs whilein subsequent calls this time is 0.
The Idle time out is also set high and connection time out is also high in the IIS settings.
server is - Windows 2008 R2.
there is nothing in the event viewer related to the website.
we used form authentication but the time out for that is also set about 10 hours in the config file.
Can anybody point me to the setting with is affecting the response time after the app is idle for some time.
Note - this was working proper when deployed withing the LAN but this problem starts when deployed out of the LAN or in separate domain.
Problem
here is the problem in IIS app pool idle time out, its by default set to 20 minutes, after 20 minutes app pool shutdown if no request within 20 minutes,
when any request comes after 20 minute its again start,
The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. so it may take time 20-30 seconds or depends on the application content size.
Solution
so to avoid this type of delay we need to set the idle time out to 0.
now it will always load fast.
app pool setting
The IIS application pool is shut down after 30 minutes of inactivity. After that, when you make a request IIS basically has to start the website up again, which leads to the behavior you are describing. You can change the idle time of your website in IIS though to avoid it.
You could also look into the Auto-Start feature of the 4.0 framework.
Well, a bit late, but may help someone else. I had the same problem, nothing in the logs, spent days, then looking at the network adapter properties / configuration / power management - Allow computer to shut down save power was checked. Unchecked and the problem was solved.
I'm troubleshooting restarts in an ASP.NET application. The application is restarting about 20 times a day. We strongly suspect one part of the application because the restarts began when this particular feature when into production. I've added some logging to those pages using the log4net library, but I'm having trouble interpreting the logs.
When an ASP.NET application is running in an Application Pool, does only a single instance of that application run, or will multiple instances of that application run? I know several worker process threads will be spawned. What is the relationship of the worker process threads to the application(s) running in the App Pool?
I am thinking that I may not be interpreting the results correctly if there are multiple applications logging to the same log. If one is restarted but the other is not, the logs aren't really telling me much about what was happening when the restart occurred.
UPDATE 1
Looking at this page, I find the following information:
An application pool defines a group of one or more worker processes, configured with common settings that serve requests to one or more applications that are assigned to that application pool. Because application pools allow a set of Web applications to share one or more similarly configured worker processes, they provide a convenient way to isolate a set of Web applications from other Web applications on the server computer. Process boundaries separate each worker process; therefore, application problems in one application pool do not affect Web sites or applications in other application pools.
But I am still confused. I know from experience that I can assign two entirely different applications to use the same App Pool. Does that mean that exactly two worker processes will be spawned? Or can there be multiple worker processes spawned for the first app, and multiple worker processes spawned for the second app? If a problem happens in one worker process, can it take down every application running in that App Pool?
UPDATE 2
From this page about using WinDbg, I found this information (emphasis mine):
In IIS 5.x, there is only one Aspnet_wp.exe worker process and one debugger thread. Consequently, only one debugger can be attached to the Aspnet_wp.exe process at a time. This can pose a problem if you're dealing with multiple Web applications on the same machine. In IIS 6.0, you can coerce an AppDomain to run in a separate application pool. (For more information, see "IIS 5.x Process Model" and "IIS 6.0 Process Model" in Chapter 1.) Separate application pools provide multiple W3wp.exe processes. Multiple debugger threads are created in these processes (one in each), allowing you to debug more efficiently.
This sounds to me like each App Pool gets one w3wp.exe process. Am I interpreting that right? And if so, does that still apply in IIS 7.5?
Yes, each application pool is typically a single process1, but can contain multiple threads. You can assign multiple sites to an application pool, and those sites will all run under the same process, however they will run under different "app domains", which are security contexts that separate the code of one site from another, even if they're running on the same app pool.
Two users hitting the site at the same time can run on different threads, meaning they can run concurrently. That means any logging can have values interspersed. You might want to add a session value to your logging so you can sort based on session.
App pool restarts (recycling) are normal, 20 restarts in a day does not seem unusual. They can happen multiple times per day, and IIS controls when app pools are restarted. It does this whenever it feels it needs to clean up the pool.2 Your applications should be written in such a way as to recover gracefully from this (ie, do not keep anything in session that cannot be easily recreated if the app pool restarts).
The app pool can also restart when an unhandled exception occurs in your app. In that case, you want to address the cause of this. Such exceptions are usually logged in the event log.
1 – While you can configure an application pool to have multiple worker processes (this is known as a Web Garden), this is not a typical (nor generally recommended) configuration in my experience.
2 – Note that using IIS Manager you can configure an application to log recycle events to the Windows Event Log. You can also use IIS Manager to set the threshold for when several of the different types of recycle events occur.
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.
I have a ASP.NET web application running on an IIS6 server. The application is making potentially long running calls to a xml service on a remote machine. Some of the service calls on the remote machine are taking a long time to execute (sometimes up to 4 minutes). The long term solution would be to make the calls asyncronous, but as a short term solution we want to increase the timeout for the calls and the overall httpRequest time out.
My fear with this is that the long running calls will fill up the request queue and prevent the "normal" page requests from completing. How can the server, IIS and application settings be tuned to temporarely resolve the issue?
Currently there are approximately 200 page requests/minute and this results in 270 service requests/minute.
The current executionTimeout is 360 (6 minutes)
The current service call time out is 2 minutes
There's this article on Microsoft's Knowledgebase that has some pretty much all the information you might need:
* Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
I will give you some research I have done regarding some of the specific items handled in the article above. This information below applies to IIS6, comments for IIS7 where applicable.
Increase the Processor Worker Thread pool from 25 to at least 100
The default values for the Threadpool size is 100 because the default value for autoConfig is true.
The values covered by autoConfig is
maxWorkerThreads
maxIoThreads
maxConnection
There is one value that is still 25 that must change is – ASPProcessorThreadMax, this can only be set in the IIS metabase (via adsutil tool) in IIS6. [IIS7’s equivalent is the processorThreadMax value]
So I'm opting not to change the machine.config settings as they are fine and there are other paramaters that would be affected by turning off autoconfig, but rather change ASPProcessorThreadMax from 25 to 100 via the IIS metabase (the only way to change this value).
e.g.
cscript %SYSTEMDRIVE%\Inetpub\AdminScripts\<nowiki>adsutil.vb</nowiki>s SET W3SVC/AspRequestQueueMax 100
Max connections per server
maxconnection
The autoconfig sets this value to 12*number of cpu’s, that’s how many connections can be made to each address you are connecting to at one time.
Debugging
Here are some things you can do:
Monitor if requests are waiting in the queue
Monitor the following counter:
Run perfmon
Add counter: ASP.NET Applications/Requests In Application Queue
This will show us if work items are queued because of a shortage of workers.
Check Identity Used by Application Pool
Open IIS Manager
Check which application pool is used by your site in IIS manager.
Choose the Application pool being used in the Application Pools list, then Right Click -> properties and see what account identity is being used.
It should be Network Service by default.