All,
I have developed a WCF ODATA Services application and hosted it in IIS7. The service application has an in-memory cache which loses all its cached value if the client is idle for about 15 mins or so.
While troubleshooting, i figured out that the application logic is proper and doesn't do a bulk removal of objects from the cache.
So, I am puzzled if IIS does clears the service objects when there are no client connected to it for quite sometime.?
Is this GC behavior true? If so, how do i control it?
Any help is much appreciated.
Thanks
By default the IIS7 Application Pools have a 20 minute Idle Timeout value set after which the application pool is unloaded from memory along with all your cached data.
You can increase the Idle Timeout or even set it to '0' which causes it to never timeout by selecting the application pool hosting your site in IIS Manager, choosing 'Advanced Properties' in the Actions pane and then setting the value of 'Idle Time-out (minutes) value' to the new timeout you want and clicking ok. (There are a couple of screen shots of this on Brad Kinsley's blog posting 'IIS7 Application Pool Idle Time-out Settings'
One option to consider is setting up an out-of-proc cache so that even if IIS does recycle your app, the memory cache persists or setup a backing store for your existing cache so that if the app pool recycles the cache re-populates from the backing store.
The Enterprise Library's Caching Application block is one example of a caching solution with such a backing store. See 'Caching Application Block and database backing store' for more information on that.
Related
I thought there was a setting that causes IIS to wait for some period of time before restarting when a file change is detected. Or something that would work similarly?
File changes are not the cause of application pool recycling. In addition to the default collection every 29 hours, the other way to allow the application pool to be recycled is to set a specific time or specific request amount or memory usage. It can also be recycled manually.
After the file is changed, the update is applied, not because the application pool is recycled, but the application is reloaded by IIS or ASP.NET, and w3wp.exe is always the same in the task manager.
I think I was thinking of the compilation optimizeCompilations setting.
I have a website in IIS 8.5.9600.16384, we communicate with thousands of mobile devices through cyclic synchronisation and through SignalR 2.3.0.
This morning we had an application pool reset during working hours, which caused the SignalR to call "OnReconnect" of all our mobile devices at the same time.
I though that IIS started new processes first and then killed the old, not having downtime.
Can somebody tell me exactly what happens when IIS recycles it's application pool on the SignalR side? And in which cases can there be a connection downtime? (ex : if the server is busy?)
Edited : The application pool was recycled by IIS because of the "time limit". The IT team will change this setting so that the application pools reset every day at night time when it will have a lower impact on our applications.
A worker process with process id of '8720' serving application pool 'DefaultAppPool' has requested a recycle because the worker process reached its allowed processing time limit.
Also confirmed that disallowOverlappingRotation is not set to True. Any hint would help.
A few years later, I'm still getting some problems with the application pool recycle and SignalR. We are occasionally seeing thousands of re-connections of SignalR while the application pool recycle occurs, opening more than 60k TCPIP ports and causing a crash in IIS.
We managed to have it run "okay" for quite some time but it still crashes. Any hint would help. thanks
I'd first identify how IIS was reset. If you experienced a crash or performed an IISReset, the processes would be down before a new one stood back up. If on the other hand you configured AppPool recycling, then the overlapping processes should occur as you mention. I would check the System Event Log for recycling messages. Note that not all recycle reasons are logged by default.
You may also check to make sure disallowOverlappingRotation is not set to True.
Specifies whether the WWW Service should start another worker process to replace the existing worker process while that process is shutting down. The value of this property should be set to true if the worker process loads any application code that does not support multiple worker processes.
https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/applicationpools/add/recycling/
I have a web application hosted under IIS. It is a data warehouse, and during its startup process it requires instantiating a large set of items in memory (takes roughly ~20 minutes to fully set up). Because this website is critical to our company, this system must be online 100% during the daytime, and only can be restarted during off-work hours.
For some reason, this web application seems to be "offline" when there is no usage for some time. I know this because the cache is not fully instantiated when the website is visited. This is unacceptable.
It is not clear to me why the website is shut off. The application pool is only set to recycle daily at 4:00 AM (it is 11 AM now).
Are there other settings which I'm not aware of on the IIS part that causes it to shut down the website automatically?
Addl Note: The website does not shut off automatically when running in IISExpress in Visual Studio. Only the production version hosted on IIS shuts off.
Here's a screen of the Advanced Settings for the Application Pool the web site is running under. (Not sure if it's useful.)
I'm on IIS 7.5, Server 2008 R2. It is an ASP.NET 5 Web App.
Check Idle Time-out settings under process model in screenshot. That setting is causing app pool shutting down when remain idle for 20 mins. You can set it to 0 to keep it running all time even when its idle i.e. not processing any requests.
Note: Keeping app pool running all time will consume server's precious memory. It may become critical especially if application is leaking memory.
In our still-in-development project we have noticed sudden delays when accessing our ASP.NET Web API services. Using the awesome Mini Profiler we nailed it that these delays are caused when connections to the Azure Data Cache (Preview) services are dropped and they have to be reestablished. This process takes about 3.3 seconds. After reconnecting, getting an object from the cache takes 1.4 ms.
When I increased maxConnectionsToServer from 1 to 20, I noticed another thing. If I don't make requests to the Web API for 1 or 2 minutes (that's usually when the connections are dropped) and then start making calls, next 20 requests are delayed for 3.3 seconds, which is how connection pooling works I guess (round-tripping the connections from the pool).
Both the Web API and Caching service are hosted in the East US region, we have disabled local cache, SSL is disabled, auto discover is enabled.
So, I'm wondering if something is wrong with our configuration or is this a thing because Azure Cache is still in preview?
Any information will be valued.
Thanks!
It sounds like your shared cache is being offloaded due to inactivity. One way to test this would be to add an In-Role Cache to an existing service (if available) and swap your cache usage to this new cache. In-Role cache is described here.
Once the cache is moved off of a shared offering, wait the requisite 1-2 minutes for idle time out and retry the connection, the delay should not be present.
Assuming you want to stick with the shared cache option after isolating the problem, the only current workaround that I am aware of is running a background task that will periodically ping the cache to keep it alive.
If you are running a full Web role you can launch a background task on application start up.
If you deploying via Mobile Services, then you can run the "ping" via Scheduled Jobs. The only issue you may run into here is that the minimum time for a scheduled job is 1 minute, which may not be aggressive enough to keep your cache alive 100% of the time.
Nothing that I see points to you doing anything wrong per se. It may be the Azure is genuinely having problems getting the cache connections up and running quickly. According to several best practices documents and MSDN posts, you want to increase your number of connections to caches to allow for a failover to an active connection, which you've effectively done with your configuration change.
Try making sure that your cache accessor is a static object (another MSDN recommendation) and this may be a long shot but consider using the Sliding Window option for object expiration and see if that not only tells the countdown for the object store to reset, but also prompts the cache service to reset the connection.
when we recycle app pool , will it crashes my website.
we have a basic public website. does recyclying the apppool every week causes the site to crash or it just kills the session of the users
we have system of out memory issue at the moment , until the we are recycling the app pool
If you keep your sessions InProc (default) then yes, recycling the application will kick out any logged in user, they will lose their sessions.
Out of Memory could be caused by many things. See How to Troubleshoot Out of Memory Issues (System.OutOfMemoryException) in ASP.NET