When adding items using the default insert method Insert(key, value) and as such using the default behavior of HttpRuntime.Cache, when does the scavenging take place?
The limit on the application pool that hosts my application is 0 (unlimited)... but I see no way to find out how big the cache can get before scavenging occurs? The problem is I am caching a potentially very large amount of data but I have limited memory on the server and I want to avoid recycling of the app pool.
I am asking in the context of IIS6 and IIS7.
Thank you.
The short answer is that the cache begins to scavenge at Cache.EffectivePrivateBytesLimit.
The default limit is calculated using a number of factors, and generally should keep your process from excessive recycling. Ideally an application won't be affected by a recycle, but I realize there are many reasons why that isn't always possible. If needed, you should be able to set memory limits for the cache in coordination with the app pool recycle settings.
Thomas Marquardt from the asp.net team wrote a very interesting post explaining the details.
Related
My shared hosting provider set up IIS recycle app pool every 3 minutes for idle.
So my session factory often recreates (at application startup). As I have about 70-100 entities it takes about 2-5 seconds to construct factory. So cold start of my application is rather long. I haven't access to IIS setting.
You can offset a lot of the cost of setting up your factory by generating your proxies at build-time instead of runtime. This article explains the steps how.
Being realistic, the simplest change is to ask that the app-pool isn't recycled so frequently (since this is an expensive operation for your application). I'm sure they've set the timeout very low as a "performance" setting, but really this is generating work and slowing things down.
You might not have access to the IIS settings directly, but this shouldn't stop you from contacting your supplier's technical support and getting it resolved.
If you are in a full trust environment (doubtful, but provider may be willing to work with you on this), you can try serializing your configuration so it doesn't need to be rebuilt each time. Merging all your entity mappings into a single XML doc can help also (just do this as build step so its not a nightmare to work with mappings).
More info here: http://nhibernate.info/blog/2009/03/13/an-improvement-on-sessionfactory-initialization.html
Have you tried to stop your site from being idle in the first place? I use uptime robot that is FREE and pings your site every 5 minutes. The benefit of this service is that it only requests the headers of the page you set up as a monitor and therefore does not affect logging such as Google Analytics.
However said you will need to test this to see when your app does indeed recycle to see if uptime robot works with your shared hosting provider. The best way is to log every time the session factory is re-built.
not much you can do. app pool recycle shuts down your app...
I guess you could try to fool the recycler by having the application do something every 2:45.
How much space IIS 6 and 7 appropriate to any asp.net application for sessions?
have this space limitation?
thanks
AFAIK, In-Process Mode is limited only by the RAM available on the server. Do you have specific concerns that you might exceed available RAM? If so, either increase your RAM or use an alternative session state mode:
http://msdn.microsoft.com/en-us/library/ms178586.aspx
There are so called sessionstateprovider. So you can actually choose. The ones I'm aware of are:
In memory
Session state service
SQL server
Velocity
Velocity is a distributed caching that can be used as session state container. I think it's now called or part of AppFabric.
The size of a session depends on your app. There is no real hard limit I know of. The best thing is to keep it as small as possible, but again, even large sessions could be required and if planned for are probably no problem.
I get this message too often and think that it is not usual, how i can fix this issue?
A worker process with process id of '8052' serving application pool 'mywebsite.com' has requested a recycle because it reached its private
bytes memory limit.
Hi this is not an expire because of a timeout, it's an application pool recycle due to memory limit. Usually very bad.
if you have full control of your ASP.NET application I suggest you profile it carefully and detect where you are allocating and not releasing / disposing a lot of memory.
It might help to understand what are the common use cases users are going through more often and start investigating those.
Are you loading a lot of byte[] in memory for file downloads?
are yoou keeping too many references in the Session?
once we had a similar problem and we found out only after several weeks that we were storing a reference to pages in the Session so all visited pages were kept in memory all the times. Not easy to find but once we corrected this the problem was solved.
You probably have a memory leak. There are many possible causes, possibly session or request instances registered with static events. Operations that are trying to load too much data into memory, session timeouts set too long etc.
You need to do some profiling to identify the cause.
Of course its also possible you just don't enough memory for the number of users and need to scale, but it's highly unlikely unless you have a lot of traffic.
Maybe your application use a lot of memory? Regarding to this post you have reached allowed memory size for application and IIS restarts the application pool.
I have a number of ASP.NET (4.0) web applications that appear to leak (a small amount) of memory during each request. It is such a small amount, that for most use-cases, it will not grow to become a problem for weeks or even months at a time. I generally try to be good with closing any connections managed by the application, avoiding state-variables (or instance variables for my singleton), etc.
My question is this - is this normal behavior for ASP.NET applications? I had turned off the default (IIS 7) behavior of recycling the app pool after 20 minutes of being idle. I do this since the application takes a few minutes to build its internal cache, and I want to avoid negatively impacting the user experience (and having them wait for the application to start when they issue the request).
I am aware this could be mitigated by serializing the cache or speeding up the cache generation process but my question has more to do with the principle of it: I personally consider relying on the IIS auto-recycle feature as a bandaid approach. Am I wrong? am I just not seeing the garbage collector at work because the application's memory usage is not high enough compared to the amount of available memory? or should I dig deeper into the memory issues?
Any insight would be appreciated.
Unfortunately it is normal, though mostly dues to shoddy application writers than anything else.
IIS by default configures newly created application pools to recycle every 1740 minutes for this reason.
As you said, this is a band-aid. A well written application that clears up all of its resources (including dangling event handlers), shouldn't leak at all.
See this blog post about the subject.
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