If I put a cache item to ASP.NET cache and set the expiration time, e.g. 1 hour, is it possible that it will disappear from cache before it has expired?
I guess it might happen if cache does not have enough memory.
Thanks
Maxim
Every cache-engine implementations has its own eviction policies. Data are often evicted because there might be a risk of running out of memory. Cache might choose to evict Least Recently Used (LRE), or Least Frequently Used with Dynamic Aging (LFDA), depending on its settings.
In order to avoid eviction issues, check your cache memory usage and limits, and set eviction configuration options accordingly.
Related
I came across a scenario where my manager is asking me to increase the session timeout since a particular user is taking lot of time in providing details to make an order and thus loosing the session state by the time they place the order.
I am just wondering if there are going to be any repercussions for increasing session timeout since this is a application level setting not a page level setting
Session timeout configuration depends on kind of website you are using. unless case of Payment or same product used by multiple users,you can set session timeout to whatever best suites for you.
It may consume memory but is fine to increase.
Suppose we have a website with 100k active users.
If we want to save email, name, last name and gender of users in sessions, how much space is allocated to all the sessions?
Are the sessions affecting server RAM, server bandwidth or something else?
Please give me a little information about session functionality and effect of session overload on the server.
The session themselves will consume the server RAM if your mode is set to InProc, which is limited only by the amount of RAM available to the worker process.
Considering your high demand, you want to be really careful what you're putting in the session, only when it's absolutely necessary. Don't put things in session and leave them there for use in a page or two, just go back to the database and get them, otherwise your session size will creep up drastically.
Based on what you're storing, it's only 5kb or even less, so based on 100k users, that would be:
5kb * 100,000 = 488.28MB
So you see, even though you're only storing a couple of details, at that level of usage the memory usage is quite significant.
For such high demand and usage, I would consider using a dedicated state server (StateServer mode) which allows you to manage it separately and allocate the resources to that server as required.
The other option is using SQL Server session (SQLServer mode) which is limited only by the size that is available to the database. So we're talking hard disk space here and not RAM. To be honest though, if you're going to the database to retrieve your session information, then why not just go to the database and retrieve the information you need anyway?
I would recommend you to store such data in the client when you have 100k users. Your pages will be larger and require more bandwidth but you will allocate less memory on the server.
If you talking about a ASP-application check this article http://www.codeproject.com/Articles/416137/Understanding-Session-Management-Techniques-in-ASP
NOTE:
This answer was posted when the OP asked about php and asp.net
Are the sessions affecting server RAM, server bandwidth or something
else?
Sessions are affecting server RAM
Please give me a little information about session functionality and
effect of session overload on the server.
If the effect of sessions overload the server, the server will run slow because of the usage of the RAM.
Most of the settings of sessions can be changed in the php.ini file
If you want to know more about session functionality, you should check out the pages about sessions on php.net or even the wiki.
There is too much information about sessions to actually post in an answer.
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.
Can anybody explane me what is "CacheSpecificEviction" in detail and how to avoid it?
I am geting this in CacheEntryRemovedArguments.RemovedReason.
CacheSpecificEviction as reason for removing cache entry means "the item was removed, because the cache provider's eviction policy determined it should be removed" - I know, it is pretty unspecific, but it hardly can be more specific, because of many possible cache-engine implementations and their different eviction policies (often configurable, for example in AppFabric Cache aka Velocity). In generel, eviction means "ok, there are risk of running out of memory, we should remove some items - for example these Least Recently Used (LRE eviction policy), or maybe Least Frequently Used with Dynamic Aging (LFDA), etc.". So to get rid of eviction problems, you sould check your cache memory usage and limits, eviction configuration options...
I am using ASP.NET's data caching API. For example:
HttpRuntime.Cache.Insert(my_data, my_key);
Is there any way to configure cache so its contents are preserved when the App Domain recycles?
I load many object into cache, but there is a substantial delay re-loading these every time the app domain restarts. Assume for this question that I can't prevent the appdomain restart due to a server configuration.
Is there any way to configure cache so
its contents are preserved when the
App Domain recycles?
No. The Cache object holds references in RAM. Period.
Alternatives:
Out-of-process Session state (although that's per-user)
Distributed cache
Use SQL Server as a cache (where it keeps data in memory, rather than on disk)
Write the objects to disk at the web tier
I generally prefer #3 myself, although there are scenarios where the others are appropriate.
Recycling the appdomain dumps the cache. If you want to get around this you'd need to use a distributed cache. Here's an example.
For your most expensive data you can cache the objects with a distributed cache such as Memcached or velocity. Depending on the size of the object and the length of runtime you could also serialize it to disk or to your database provided that the access speed to these resources is less than the time to create the object.
Now since the in-proc cache is super fast compared to any other solution since it just holds a reference to the memory object you will want to use it where possible. You can keep a copy of your cached object on disk until it is lost and then re-create it from that and place it in memory. Where this is tricky is when you have to expire the data so only use the cache/disk/sql combo where you won't need to expire/invalidate the data otherwise you will need to ensure that you clear both. This will also get around not being able to implement distributed caching on a shared server for example.