InProc Advantages and Disadvantages
InProc is default mode which works without any
configuration. It is easiest option to implement because you don't need to
configure anything. Just read and write session variables in code. Other modes,
like SQLServer or StateServer modes require additional configuration.
One more advantage of InProc mode is that you
can put anything in session variables. State Server or SQL Server requires
objects to be serializable. But, if you use InProc, you can save any object in
session variable even if it is not serializable.
InProc mode works on shared web hosting. State
Server is usually not allowed, and some shared web hosting providers give
option to use SQL Server. In the other hand, InProc works in any hosting
package.
Reliability is first problem
when using InProc. When using InProc mode, all sessions are lost whenever web
application restarts. Restart could happen very frequently because of numerous
reasons (see Restart
and Stop of ASP.NET Application tutorial) so InProc mode is not enough
reliable in many scenarios. If you change web.config, Global.asax, any file
inside App_Code folder, change anything in /bin folder etc., ASP.NET
application will restart. Also, application will restart if too much memory is
used, certain number of compilation is reached etc.
If InProc is used, each time web application
restarts or get recycled, all session variables will be deleted.
This could harm user's experience. If user was in the middle of long task,
losing of session means that he or she must start from the beginning.
Scalability is one more problem
when using InProc mode. Each user has its own collection of session variables.
On high traffic websites, with thousands of visitors online, sesssion data
easily grow and spend complete memory on web server. When there is not enough
physical memory, Windows will start paging on disc which slows down application
and decreases performances.
This could happen even on small traffic
websites, if large objects are stored in sessions (e.g. data tables) or session
timeout is increased a lot (in this case, Session State keeps data of many
inactive visitors).
There is a problem on web farms and web
gardens. If you host website on web farm (multiple servers) or web
garden (multiple processors) ASP.NET application will use multiple processes.
Since InProc stores session data inside single process, session data will be
lost when visitor request goes to different server or processor and will be
readable again if request goes to process where session is written. You can't
know if next request will be directed to same process or not. This kind of
error could be very confusing since sessions disappear and get back on every
refresh :). Possible solution could be to use load balancing to direct every
request from one user to same server (e.g. based on visitor's IP address).
But, since websites on web farms are usually
large sites with a lot of traffic, they also experience previous problems with
reliability and scalability. So, better option is to simply move to State
Server or SQL Server mode. State Server and SQL Server store sessions outside
of ASP.NET process and therefore sessions' variables are accessible from any
server in server farm, or any processor in web garden. You can add additional
servers or processors when needed.
Serialization/Deserialization
is potential problem. InProc doesn't require serialization of complex objects.
This is basically advantage, but in practice could be big problem when you least
expect. Since InProc allows to put anything in session, you could end up with
many non-serializable objects in session. If you need to switch to Session
State or SQL Server later (e.g. your website became popular and now you have
many visitors), you can't because stored classes are not serializable. Suddenly
something that looks like advantage becomes a problem and you must change all
problematic objects at once.
So, good practice is to avoid storing of non
serializable classes in Session State. On this way, you can change session mode
any time if needed. When you developing new application you can use State
Server from the beginning, to be sure that all objects in session are
serializable.
Comments
Post a Comment