If the leave the webpage (any webpage) on my web application for a while (say 15 min), if I again click on another page it takes a long time to load (20 seconds)
I had a look through the google chrome --> developer module and found that, it is the web page which is the culprit here and the 'LATENCY' time for it is 17 seconds !!! and the actual 'download' time is only 117 ms.
A. what could be the cause of this issue?
B. What can I do to fix it?
thanks.
By default in IIS, your worker processes will idle timeout after 20 minutes and have to be reloaded. This is a configurable setting.
Here's the documentation for IIS6
I am quite certain that it is caused by your worker process recycling. Go to your IIS and check the application pool setting. There is a setting to say that it will automatically recycle after certain time. Either turn it off or increase it
I can't really give you a specific answer here, as I don't know exactly what you may be doing with your application. However, ASP.NET and IIS will not keep everything your web app uses in memory forever. There are two things that could be the culprit here:
1) Your ASP.NET session is timing out, and you are putting something large with a lengthy load in the user session.
2) The IIS app pool is recycling after its idle timeout.
I think that the timeout for both of those is 20 minutes, which would roughly correspond with the 15 minutes or so you are seeing.
Related
I have an ASP.NET app that runs on IIS. The first time I visit the webpage, it takes several seconds to initialize. All subsequent visits to the site is fast.
However, after approximately 24 hours, the cached application resets automatically; causing the ASP.NET app to take several seconds to start again.
How do I disable this IIS feature so that the cache doesn't reset?
The closest thing I could find to this is to disable the ASP.NET app pool; which the default is 1740 minutes (1 day, 5 hours).
I tried disabling this feature, however, it doesn't seem to prevent the cache from being reset.
I'm working with ASP.Net web services and am having a problem with a long-running process that takes about 5 minutes to complete, and it's timing out. To fix this, I was able to set the executionTimeout on the server's web.config to 10 minutes, and then set the .Timeout property on the Web Service object to approximately 9 minutes. Now, I'm worried that this may possibly cause some other web service calls to sit there for 10 minutes before they time out rather than the previous 90-100 seconds. I know the default on the client side is 100 seconds, but wasn't sure if updating the server's timeout setting would affect this.
Bottom line is - Is it safe to update the server's timeout setting to a long amount like 10 minutes, and rely on the default timeout on the client, or could this end up causing some problems?
Thanks!
The web is not supposed to work like this. If you have a long running process, you should call it in a new thread and post the answer after the page has finish loading on the client side (either with a callback or by querying the server-side every x minutes to check if the process has finished). This way you avoid timeouts and the user gets their page (even incomplete) in a user-friendly time. This is important because if the user does not get their page in a reasonable time, they will be unhappy and try to reload the page (and maybe restart your process...).
It looks likes if I don't visit my low traffic site for a day, it takes a long time for the first page to load. I believe it's probably because IIS7 shuts down the application when it receives no requests for a certain length of time.
How can I stop this from happening?
I have a dedicated server so I have all the access required to change things in IIS
There are two ways that you can handle this.
Modify the "Idle Timeout" value within the application pool. By default it will shutdown the application if there are no requests for 20 minutes
If you are using ASP.NET 4.0 you can use the new Auto-Start behavior to keep the app "Always Running" you can see this blog post for examples on how to configure it.
The app pool goes to sleep basically because it has no new requests to process in a certain amount of time.
There is a plug-in for iis that can fix this:
IIS: Application Initialization Module for IIS 7.5
Works great for both new deployments and idle applications.
Take a look at the application pool, check the advanced settings->process model->idle timeout (minutes). Set this higher than 20 mins. Sounds like the worker process is shutting down because its idle.
http://technet.microsoft.com/en-us/library/cc771956(WS.10).aspx
Cheers
tigger
when I access any page of my ASP.NET MVC website first time, then this first request is slow. It needs about 4-5 seconds to load. But every following request to any page is fast.
When I wait some minutes or a hour then every first request is slow again. Every following request is fast.
I think that IIS 7 is compiling the code and keep it in memory. After some time it will delete it from memory so it needs to compile it again.
What can I do that every first request is as fast as every following request?
(Without precompiling my source, if possible)
Thank you very much in advance!
If this is a production server then why not try adding a website monitor; such as up time robot. It basically asks for your websites headers and gets status codes like "200-ok", "404-not found", etc. every 5 minutes. This way your site is always spun up and does not impact log files/analytics as only headers are requested. I use this for my cloud sites as I find that they take 5 seconds to spin up which has an impact on site loading. With the monitor they are instant.
Oh and its free for up to 50 sites!
This could be the recycle worker processes setting on the application pool, check the value for that and either turn it off or make it longer.
Could also be the Shutdown worker process after being idle under performance for the application pool.
It's probably the second as that defaults to 20 minutes, the first one defaults to 29 hours I believe.
This is almost-certainly your app pool idle timeout setting (and not your code being recompiled).
The default app pool idle timeout in IIS is 20 minutes. Which means that, if 20 minutes pass and no requests come in to your app, IIS will shut down the worker process for your app pool, making your app "cold" again. Whoever makes the next request will be waiting several seconds as IIS restarts the worker process and "warms" your app back up.
If you don't want IIS to automatically "cool down" your app after a period of inactivity, you can disable the app pool idle timeout by setting it to 0.
Assuming that you have a regular stream of visitors, this should not be a problem in production. Also, unless you're physically altering any of your source files, IIS would not recompile it when it spins up your app.
Also, take a look at the .NET compilation settings available:
http://technet.microsoft.com/en-us/library/cc725812(WS.10).aspx
tl; dr
After quite extensive testing and gathering of relevant sources to attempt to resolve the issue, I think that the minimal solution may be (not verified) to add this code to the global.asax:
protected void Application_End()
{
...
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://web_domain.tld");
using (HttpWebResponse response = (HttpWebResponse)
request.GetResponse())
{
}
...
}
In the time of writing the post, this is used to effectevely maintain the site I worked on 'always-up' - with conjuction of setting the Idle Time-out (minutes) in IIS to 0 as mentioned in other answers. However I think that changing Idle Time-out (minutes) may not be necessary (assuming that Application_end event is raised when the switch of application pool to Idle mode occurs).
How it works (assuming it does):
There are 2 settings in the IIS application pool settings that affect when the application is suspended or terminated. One of them is Idle Time-out (minutes) which defaults to 20 minutes and when the specified time elapses since the last request, the worker process is suspended or terminated. When a next request comes, the worker process is resumed or started again and the Application_start event is raised (and so if the Application_start handler is defined in global.asax, it is executed). In case of the project I worked on, the Application_start took about 17 seconds to complete. So if the site was 'left alone' for 21 minutes and then the new request came, it took about a little more than 17 seconds before the response was sent back (Application_start + page processing). When another request was sent in the window of 20 minutes, the response was sent significantly faster (perhaps less than 1s), since the Application_start has already been processed.
Setting the Idle Time-out (minutes) value to 0 causes the worker process to never be suspended / terminated (at least due to the idle time - there may be another cause described below).
Apart from Idle Time-out (minutes), there is also the Regular time interval (minutes) setting in Recycling section of the IIS advanced settings. This defaults to 1740 minutes (29 hours) and is a regular scheduled task that causes the Application pool to periodically recycle (the period is fixed). This, I understood, is to prevent the accumulation of possible memory-leaks which, if present, may eventually crash the server by exhasting all the memory. The effect of app-pool recycling is that Application_end event is raised. However, after the application ends it is not automatically started again, so the Application_start event is not raised until an actual request comes (which is similar to the first case). So in the case of the aforementioned web application I worked on, it would again take about 17 seconds to process the first request to arrive after the recycling occured. Changing this value to 0 turns the recycling off, but I suppose that it is reasonable not to turn the recycling completely off due to the possibility of accumuluation of memory leaks over time (which may possibly even be caused by bugs in 3rd party libraries). I understand that the opinions differ on whether to set this value to 0 or not and may change over time.
Posible solution (without changing IIS settings):
If the requests are sent frequently enough, the app-pool may never switch to Idle mode. On the event of recycling, this would also cause to the application to start again. This can be achieved, for example, by using 3rd party service as described by #Rippo.
Proposed solution:
It has been observed that application pool recycling caused Application_end event to be raised. Assuming that it is also raised upon switching of the application pool to Idle mode, it would seem to be sufficient to create a request in the Application_end event handler to the website, which in both cases would then cause the application to start again (raising the Application_start event). The code is at the top of the answer.
I have a WCF service that requires a certain response time (under 1 minute).
My problem is that every so often, most often in the mornings the service takes a long time to respond (sometimes over 2 minutes).
I'm thinking this is because the app has recycled and the first run must recompile.
Are there other reasons this might happen?
Is it possible to turn off app recycling? And if it is, will that cause any side effects or instability? I'm assuming there must be a reason why asp.net apps are set to recycle.
Is there anything else that can be done to improve that first run performance?
Yes you can prevent the AppPool from recycling. Another option would be to create a keep-alive job to continually ping the service to keep the worker process from sleeping.
Basically the following rules dictate when an application is recycled or unloaded:
After the App Pool Recycle time has been reached - by default this is every 29 hours I think.
A set time after the last request to application.
Using a keep-alive to ping the service would solve 2, and then you'd just have to deal with 1.
Depending on your version of IIS, there are slightly different ways to configure this.
For IIS 6
For IIS 7
The idle time out I think would normally default to "infinte", but can be configured through the processModel element (idleTimeout attribute) of your configuration files.
As to first run performance - without looking at your app it's hard to say, have you run something like DotTrace or another profiler over it?
Are you doing a lot of intensive lookups and caching data in that first load? Can these be deferred?
Performance problems can be caused by anything you haven't ruled out first. Since you haven't ruled anything out, it could be cauased by anything at all.
Maybe a silly idea : could you schedule a console app to hit your service at e.g. 5:30am in the morning, so that this request would take a long time to run, and your regular users coming in after that won't have that problem?
Sure - it's not dealing with the root cause, but for the time being, it might be a useful workaround - no?
Marc