I need suggestion for Out-Proc cache for ASP.Net application.
The HttpRuntime.Cache is In-Proc cache can't be shared by multi w3wp.exe processes.
I am ware that there are some of open source projects for this subject, like http://www.sharedcache.com/cms/
But the problem is --
1. Serialization is required to store/get the cached data, which is
slow for big object instance.
2. Some types from ASP.Net framework are not allowed to be serialized, like RouteColltion class.
Do you have any idea for a fast Out-Proc cache solution without serialization?
Serialization is inevitable when using an out-proc cache since objects are to me transmitted form one process to another process (probably on another machine), which cannot be done without serializing objects.
However to reduce performance cost of serialization, NCache a .net based distributed caching solution provides Compact Serialization feature. Compact serialization as its name suggests provides optimized serialization of objects resulting in less number of bytes as compared to native .Net serialization. Thus reducing communication time required to transmit or receive data from out of process cache.
Related
.Net Core provides in-memory implementations for both interfaces (MemoryCache and DistributedMemoryCache) but let's assume we have a working IDistributedCache implementation for our application.
When does it make sense to still use IMemoryCache. In what scenarios is it helpful or preferred over caching data in a distributed cache?
I was searching for same and found the answer in github issue:
They have fundamentally different semantics. MemoryCache can store live objects, the distributed cache can't, objects have to be serialized. The distributed cache can be off box and calls to it may fail or take a long time so getting and setting should be async, the MemoryCache is always in memory and fast. The distributed cache can be disconnected from the store so the interface should account for that.
https://github.com/aspnet/Caching/issues/220#issuecomment-241229013
By design IMemoryCache interface used when you need to implement data caching mechanism for single or multiple process on same app server.
Shortly we could say, in-process cached mechanism.
Meanwhile IDistributedCache interface been designed for distributed cache mechanism, where any data cache shared on many app servers (on web farm).
Shortly we could say, web farm data caching scenario.
Hope this could helps.
I will host my ASP.NET MVC4 app as a redundant Azure app. During a session, the app performs computationally expensive operations that produce non-serializable objects. Creation of the objects is repeatable; I could perform the expensive operation each time I need the object, but I would prefer to just do it the first time and save the object for later reuse.
I want to use the standard distributed session state mechanism in Azure for storing the usual session state info, but that mechanism requires that session data be serializable. Is there another mechanism I can use to cache the expensive-to-create, non-serializable objects?
Bob
All distributed cache services provided by Windows Azure need serialization currently, not only the shared cache, but dedicate/co-located cache as well.
But it's not necessary to serialize if you are going to use in memory cache. But this is not good for scaling-out, and you may not be able to have azure SLA if you've only 1 instance.
So my suggestion is to optimize your serialization and try to use azure cache.
Do these objects have to be stored in centralized storage or can you store them in the "InProc" session state?
If not, I'm afraid you'll need to serialize them into something (either SQL Azure, file, app-fabric cache, etc).
So either find a way to serialize them into something persistable or store them in RAM, with an extra copy on every web server
When i need to cache something in my application, i used to choose Web.Caching.Cache. But i ran into some legacy code that using HttpApplicationState instead.
Since Web.Caching.Cache is more powerful and flexible (seems MUCH more), is there a situation that better to use HttpApplicationState??
I will be very appreciate if you can show me some examples :-)
Both HttpApplicationState and Web.Caching.Cache can be used to store information that can be globally accessible throughout an ASP.Net application. However, they have very different uses.
HttpApplicationState is used to store application data that typically does not change. It is typically populated in Application_Start in Global.asax, when the application is starting. I personally have not used it much, but I believe it is typically used to store small pieces of application configuration that are global to all users of an application and which either do not change or change very infrequently. Something put into Application state will remain there indefinitely, until the app recycles. But when it recycles and restarts again, Application_Start will execute again and re-populate it.
It is important to note that HttpApplicationState is a singleton and is not thread safe. So when you make changes to it, you must lock and unlock the Application object via calls to Application.Lock() and Application.UnLock(). Read more
There are actually three different ways you can cache ASP.Net content: Page level, partial page, and data. I am going to talk about data caching, since I think that is most relevant to your question. The ASP.Net cache is used to store large quantities of application data that would be expensive to retrieve from a data store for every request. The key differences between HttpApplicationState and Cache are 1) Cache data is designed to expire and be purged from memory by a variety of triggers or conditions (time, other cache dependencies, etc), whereas HttpApplicationState will be there forever until the app recycles, and 2) Cache data can be purged from memory if a server is experiencing severe memory pressure, and you thus can never count on it being there and must always test to see if it is present, whereas HttpApplicationState will always be there.
Caching is used to store data closer to the application that does not need to be pulled from a database on every request. Caching is designed to store very large quantities of data, and an intelligent caching architecture can have an enormous positive impact on performance.
I store a large structure holding my application's reference data in a variable I access through HttpContext.Application. Every once in a while this data needs to change. When I update it in place, is there a danger that incoming requests will see the data in an inconsistent state? Is there a need (and a way) to lock some or all of this structure? Finally, are there other approaches to this problem other than querying the database every time you need this (mostly static) data?
There are also other solutions availiable, there are many caching providers that you can use.
First of all, there's the HttpRuntime.Cache (which is the same as the HttpContext cache). There's also the System.Runtime.Caching.MemoryCache in .NET 4.
You can set data expiry and other rules for the data in the cache.
http://wiki.asp.net/page.aspx/655/caching-in-aspnet/
http://msdn.microsoft.com/en-us/library/6hbbsfk6.aspx
http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx
More advanced caching includes distributed caches.
Usually, they reside on another server but may also reside on a different process on the same server.
Such providers are AppFabric (from Microsoft) and MemCached and others that I can't recall currently.
appfabric: http://msdn.microsoft.com/en-us/magazine/ff714581.aspx
memcached: http://memcached.org/
You will not see the application variable in inconsistent state.
The MSDN page for HttpApplicationState says (Under the Thread Safety section):
This type is thread safe.
You may be looking for HttpContext.Items instead to store data in the request scope instead of the application scope. Check out this article to get a great overview of the different context scopes in ASP.NET.
Your solution to avoid querying the database for "mostly static data" is to leverage ASP.NET's caching.
I have one website on my server, and my IIS Worker Process is using 4GB RAM consistently. What should I be checking?
c:\windows\system32\inetsrv\w3wp.exe
I would check the CLR Tuning Section in the document Gulzar mentioned.
As the other posters pointed out, any object that implements IDispose should have Dispose() called on it when it's finished with, preferably using the using construct.
Fire up perfmon.exe and add these counters:
Process\Private Bytes
.NET CLR Memory# Bytes in all Heaps
Process\Working Set
.NET CLR Memory\Large Object Heap size
An increase in Private Bytes while the
number of Bytes in all Heaps counter remains the same indicates unmanaged
memory consumption.
An increase in
both counters indicates managed memory
consumption
check the section on troubleshooting memory bottlenecks in Tuning .NET Application Performance
Create a mini-dump of the w3wp process and use WinDbg to see what objects are in memory. This is what the IIS support team at Microsoft does whenever they get questions like this.
If you have access to the source code, you may want to check that any objects that implement IDisposable are being referenced inside using statements or being properly disposed of when you are done with them.
Using is a C# construct, but the basic idea is that you are freeing up resources when you are done.
Another thing to check on is large objects getting put in the "in process" session state or cache.
More details would definitely help. How many applications are running inside the application pool? Are there ASP.NET applications in the pool?
If you're running ASP.NET, take a good look at what you're storing in the session and cache variables. Use PerfMon to check how many Generation 0, 1 and 2 collections are occurring. Be wary of storing UI elements in the session state or cache since this will prevent the entire page instance and all of the page instance's children from being collected as well. Finally, check to see if you're doing lots of string concatenation. This can cause lots of object instantiations since .NET strings are immutable. Look into using StringBuilder instead.
As other people noted common cause of this problem is resource leaking, also there is a known issue with win2k3 server and IIS6 KB916984