Where do System.Runtime.Caching.ObjectCache cache/store data when it is Memorycahce.Default?
Do it save data in ram or cpu L1 cache ?
How do I caching memory in task manager?
Yes those are in memory (OR) in-process cache and does store the data in server's memory (RAM) whether L1/L2 cache that no idea. So, in case your worker process goes off (OR) IIS recyles (with context of ASP.NET) then all your cached data is gone.
On the other hand, you can as well choose to use distributed cache mechanism like REDIS or Azure Mem Cache which are stored on separate server instance and not in your server process.
No, it has nothing to do with processor caches L1, L2 or others. It is just a caching (as a concept) solution ,that is being held in memory.
Related
My first impression of AppFabric Cache is that it's essentially a distributed hashtable in the same vein as memcached. The typical usage pattern of such a cache is that there is no guarantee that your data will be in the cache (old entries are evicted to make space for new ones), but with sufficient RAM they usually will be.
On the other hand MS provide a Web Session State Provider that stores session data in an AppFabric Cache. This appears to be a completely different usage pattern as we now require the cached items to never be evicted as a result of memory pressure. To achieve this MS provide a high-availability mode that keeps redundant copies of all data, furthermore eviction can be disabled, which in turn requires us to allocate sufficient RAM to ensure that the cache never reaches capacity.
It seems likely that an application would benefit from using both types/modes of cache, but as far as I can tell AppFabric RAM cannot be ringfenced within a cluster or host, hence the web session state may (and generally will) experience memory pressure in that case. The only solution I can see is to operate two AppFabric Cache clusters, one for each mode.
Is the above a good representation of the situation or am I missing some config setting that addresses this scenario?
Storing a session in appfabric is not a good idea,have faced many problems trying this(like due to memory pressure data got lost, multiple users hitting the cache to put the data can lead to data loss etc.) and now started using inProc/SqlServer session state use.
I'm currently testing out AppFabric Distributed Cache, it's been working great.
When performance testing the Local Cache feature however, I find there is no difference in performance.
For the purposes of the performance test I am storing large pages generated from OutputCache into AppFabric and am noticing the same performance with or without local cache on.
Does anyone else have any similar experience?
I'm using Timeout based local cache, with a ttl of 300 and objectcount of 100000.
If the distributed cache is on the local server, then there should be very little difference.Since the main time usage accessing the distributed cache is the transport across the network.
It may be that it takes a bit longer to access the distributed cache than the local on the same machine, since local cache is in process:
When local cache is enabled, the cache client stores a reference to
the object locally. This keeps the object active in the memory of the
client application
However, local cache does add some sync overhead. So the actual differences will depend on your usage pattern.
I think this might depend on the type of data your are caching.
We use local cache a lot for web services that have many almost identical Get methods (small data in return). The local cache gave a significant less load on the cache servers, and most transactions take 0 ms.
I'm studying for a MS certification and one of the practice tests I'm doing has a question where the point of contention is the performance between storing the session in SQL Server as opposed to StateServer.
Given the app is running in a web farm, which solution for session state gives the best performance (SQL Server or StateServer) and most importantly, why?
State Server is faster because it stores session data in an in-memory dictionary. SQL Server is slower because it's stored in a database which persists data to disk.
SQL server is also slower because everything is stored in one table which leads to contention as more and more clients access/update the session data.
SQL server is more reliable because it is persisted to disk and can be set up as a cluster with failover capability.
See the preamble in this article for an indepth explanation.
A little, but important sidenote: InProc is not usable in a farm, as the name suggests, it runs in the current w3wp proces and cannot be shared across a farm. StateServer is a Windows service, so the speed of using StateServer is dependend on how fast the machine the stateserver service is running on, it is memory only. SQL of course needs to write the data and retrieve, which is probably slower than memory only.
From here:
In process. In process will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be re-directed to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.
Out of process. This mode is best used when performance is important but you can't guarantee which server a user will request an application from. With out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.
SQL Server. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as out of process, but the tradeoff is the higher level of reliability.
From this link: http://www.eggheadcafe.com/articles/20021016.asp
Performance
InProc - Fastest, but the more session data, the more memory is
consumed on the web server, and that
can affect performance.
StateServer - When storing data of basic types (e.g. string, integer,
etc), in one test environment it's 15%
slower than InProc. However, the cost
of serialization/deserialization can
affect performance if you're storing
lots
of objects. You have to do performance testing for your own
scenario.
SQLServer - When storing data of basic types (e.g. string, integer,
etc), in one test environment it's 25%
slower than InProc. Same warning about
serialization as in StateServer.
So it would seem that StateServer is a little faster that SQL Server for storing session state.
In terms of the why, I'd suggest that the SQL Server is more multi-purpose and will likely be used for other things as well. Not only that but the storage mechanism is to disk, where as the StateServer is running in a separate process, yet it is simply storing the data in the memory space of the other process rather than having to write it to disk (virtual memory permitting)
SQL Server (In Memory) is the answer - available in SQL 2014
http://blogs.msdn.com/b/kenkilty/archive/2014/07/03/asp-net-session-state-using-sql-sever-in-memory.aspx
In particular what strengths does it have over caching features of Asp.net
memcached is a distributed cache -- the whole cache can be spread into multiple boxes. so for example you can use memcached to store session data in cluster environment, so this data is available to any box of the cluster.
memcached can be compared to Microsoft's Velocity (http://blogs.msdn.com/velocity/).
Another nice feature is that memcached runs as a stand alone service. If you take your application down, the cached data will remain in memory as long as the service runs.
We use memcached as a caching back-end in a ASP.NET web site. We have 12 memcached boxes.
UP for memcached:
Much more scalable, just add boxes with memory to spare
The cache nodes are very ignorant: this means that they have no knowlegde about the other nodes participating. This makes the management and configuration of such a system extremely easy.
All of the webservers have the same values in cache (so you never see hopping values deending on which webserver serves your request)
DOWN for memcached:
compared to in-memory cache, it is very slow. Mostly because of serialization/deserialization and network latency
The cache nodes are very ignorant: ther is, for example, no way to iterate over all of the cached items
Memcached is the simplest en fastest tool is you need distributed caching. If you can use in-process in-memory cache for your application, that will always be faster. We use a cache manager that will offload certain items to memcached and keep others in local cache.
StateServer or SQLServer?
What is the best solution for storing ASP.NET session variables?
What are the pros and cons of each?
Are one better then other in any particular situation?
Here's some thoughts about pro's/con's.
I've also added Microsoft Velocity Distributed Caching solution.
Pros for InProc
Fastest optional available (it's all in memory/ram)
Easy to setup (nothing new required in the .config file .. i think this is the default behavior).
Most people I believe use this.
Cons for InProc
If the web site (application pool) dies, then all session info is lost.
Doesn't work in a WebFarm scenario -> session information is per app pool only.
Cannot contain non-session information.
Pro's for a StateServer
In memory/ram, so it's fast (but has some net latency .. read below), so it might not be as fast as Inproc.
Default configuration for a web farm scenario. Multiple iis sites use a stateserver to control the state session info.
Con's for StateServer
Requires the ASP.NET StateServer service to be set to run.
StateServer requires some config tweaking to accept 'remote iis machine' requests.
There's some tiny tiny net latency if the iis request needs to grab/set the session info on another networked machine.
Cannot contain non-session information.
Pro's for SqlServer (as a state server)
State is always retained, even after the iis site restarts.
Con's for SqlServer (as a state server)
Slowest solution -> net latency AND hard-drive latency (as the sql server stores the state on the harddisk / reads from the harddisk).
Hardest to setup/configure.
Cannot contain non-session information
Pro's for Velocity (or other distributed caching systems)
Can handle more than just session information -> objects, application settings, cache, etc. (This is a very GOOD thing IMO!!)
Can be memory only or persist to a database.
If one 'node' fails, the system still works. (assuming there's 2+ caching nodes)
Con's for Velocity (or other distributed caching systems)
Generally cost $$$
Hardest to setup (have to install stuff, tweak configs, add extra specal code).
Has network latency (which is generally nothing) but could have hard disk latency IF the service is persisting the data (eg. to a Sql Server).
I think the assumption would be that you are using a web farm of some sort.
One use of state service is in a Web Garden (multiple worker-processes on the same machine). In this case, you can use load-balancing to keep a user's connection going to a particular server, and have the n worker processes all sharing the same state service.
EDIT: In the web garden + state service or sql server scenario, you also have the benefit of being able to recycle the worker processes on that machine w/o the connected clients losing their session.
I'm not as familiar with using SQL Server as a session state store, but I would think you would gain robustness by using an SQL Server in a cluster. In this case, you could still have multiple worker processes and multiple servers, but you would not have to use a sticky session (server affinity).
And one more note, you can use state service on a second machine, and have all server in the farm hit that machine, but you would then have a single point of failure.
And finally, there are 3rd party (and some home-grown) distributed state-service-like applications. Some of these have performance benefits over the other options, plus Session_End event will actually fire. (In both State Service and SQL Server session backing, there the Session_End in Global.asax will not fire (there may be a way of hooking into SQL Server)).
In an n-tier environment, with SQL Server hosting session state you'll create additional network traffic to your back-end, as well as losing some SQL Server resources that will need to now take care of that additional traffic (session-related requests). SQL Server state management is also slower than state server.
However, if your servers go down in some unforeseen incident, SQL Server will most likely maintain the session information, as opposed to a state server.
In my personal experience I had a few problems storing in session variables. I kept loosing the session and I believe it was the anti virus, which, as it was scanning every file in the server, IIS would recompile the site killing the sessions. (I must say I had no power over that server, I was told to host the app there)
So I decided to store the session in the SQL Server and everybody is happy now... it is incredibly fast
Take a look at this article for a quick start up
Using a single machine to store state in a web garden means a single point of failure. We use SQL state, but it does add a bit of overhead.
In Proc is very Fast.
But having limitation. we can use single system only.
When the time of reboot the System, information will be lost.
worker processes in same machine
StateServer stored the session information in other machine.
Web Farm can use the session. for ex: multiple worker-processes can access the session information from server.
When the time of rebooting server, information will be lost.
SQLServer is used to store the info in Table. Default it will store in TempDB.
This tempdb will dynamically call after sqlservice is called.
So this also not persist the data. In this Scenario we can store in our own DB using Script, that is called Custom Option.