In IIS application pool I have set 2 in maximum worker process in process model, will application object, session object and cache object will be shared by the all worker process or will all worker process have different application object, session object and cache object.
If you use in proc state management the session is kept in the running process. So if you have 2 or more workers processes your session will only work by chance. You can use SQL state management or State server.
Using a state server is pretty fast but if the stateserver fails or reboots all sessions will be lost. Using SQL server is somewhat slower but it has the benefit that the session will be all there after a reboot or any kind of interruption. So what to choose depends on your requirements. If you're running a e-comerce site or similar you could set up the sql server with clustering and multiple webservers to get a better uptime.
As for caching it is the same, the cache is kept in the worker process. Depending of how expensive it is build up objects in the cache you could use MemCached or something like it. But then you need to serialize/deseriliaze the cache objects and send them over the wire to another server, which could be quite expensive as well.
Related
I am implementing an ASP.NET application that needs to service conventional http requests but the responses require data that I need to acquire from providers that are executables that provide their data over sockets. My plan to implement was:
1) In Application_Start, start a new thread that starts a socket server
2) In Session_Start, launch the session-specific process that will ultimately connect to the socket server, and from there do a Monitor.Wait on a session-specific lock object which I've stored in Application.Contents by Session key
3) When the socket server sees a new connection, make the data available to the appropriate session Contents and do a Monitor.Pulse on the session-specific lock object
Is this technically feasible in IIS? Can this concept function as a stable system?
Before answering, please bear in mind I am not asking "is this the recommended approach", I am aware it is not and if I had the option to write this system from scratch I would do this differently. I'm also not able to change the fact that the programs communicate using sockets.
Given the constraints this approach makes sense.
Shutdown and recycling of IIS worker processes are always throny issues when it comes to keeping state in a web app. Note, that your worker process can recycle pretty much at any time for many reasons. Some of those reasons are unavoidable: Server reboot, app deployment, bug leading to a process crash. So you need to think through what happens in those cases: All sessions will be lost while the child processes still run. Suggested solution: Add the children into a Windows Job Object and configure the Job to be killed when the parent exits.
With overlapped IIS worker recycling you can have two functioning workers running at the same time. You must deal with that possibility.
Consider the possibility that the child process immediately crashes. It will never make a connection. Make sure your app doesn't hang waiting for the connection forever.
In my ASP.NET MVC application I have a number of threads that wait for a certain length of time and wake up to do some clean tasks over and over. I have not deployed this application to a production server yet but on my dev machine they seem to work as expected. For these threads to work the same on IIS7 do I need to look out for anything? Will IIS7 keep my threads alive indefinitely? are there implications to worry about?
Also I want to queue, lets say 50 objects that were created through various requests and process them all in one go. I'd like to maintain them inside a list and then process the list which means that the list object has to be kept alive indefinitely. I'd like to avoid serializing my objects into the DB in order to maintain this queue. What is the correct way of achieving this?
Will IIS7 keep my threads alive
indefinitely?
No, if the application pool recycles (if there's a long inactivity or some memory threshold is hit) those threads will be stopped as the application will be unloaded from memory. If those objects are so much precise I wouldn't recommend you keeping them in memory but rather serialize them to some persistent storage so that they could be processed later in case of failure.
The design you describe is fine when you don't mind losing cached commands in the queue. Otherwise it would be better to go with a different design. ASP.NET isn't suited for this type of processing, because IIS can recycle the process. When that happens you lose your in-memory queue. IIS could also decide to unload the AppDomain because no new requests are coming in. In that case your threads will also stop running which means that pending operations will still not been cached, even when you use a persisted queue.
You'd probably be better of with some sort of transactional queue, such as MSMQ or a custom table in the database (or look at the open source NServiceBus). Adding operations to the queue can be done by your web application and processing items can be done within a Windows service application that will not be recycled and can process the queue in a transactional way.
Since you're talking about multiple threads: when using a Windows service you can build it in such way that it can run multiple threads or make it single threaded and run several instances of the same thread. This is a very flexible design that I used successfully in the past to distribute CPU and disk intensive operations over multiple machines.
I have an ASP.Net website on IIS7 and I am planing to increase the MaxProcesses to match the number of cores on the server (4 cores, 64bit Windows Server 2008).
From what I read, if I increase the MaxProcesses to create a web garden I have to set an out-of-process state server, so I am planing to use the ASPState service to share sessions between worker processes.
But there is something that is not clear to me, is Caching also shared? Or do I have to set a new custom provider for the cache?
In-process cache is never shared in a web garden.
But here's the REAL thing... I question the motivations behind what you're doing. If the object is to use your cores more efficiently, then you can just increase the number of request and/or worker threads you have running your ASP.NET application. Running multiple w3wp processes isn't necessarily the option you want. If you have some constrained resource, like an old in-process COM object that scales poorly with threads, then I can see how you might scale better with multiple processes. But unless you really know what you're doing and why, gently step back from that setting and leave it at 1. ;-)
Caching is not shared. The web garden creates multiple "w3wp" processes. Each process will have its own cache.
If you want to share cache then use something like MemCached Win32 (with the Enyim cache client) or use the new MS product Velocity. This way once you move beyond one server you will already be set up architecturally to handle it.
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
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.