I'm not a fan of using ASP.NET session state, but our application is using it at this time. We are using SQL Server mode for session state persistence. I'm considering caching authorization check results in the session state, but I worry about the performance of this approach. How exactly does SQL Server session state persistence work in .NET?
From what I can tell, all session data is stored in one database row, with the data itself stored in one column. My worry is that if our application does 12 different authorization checks in one request, and each result is stored immediately after received, that 12 different database requests would be made as those items are stored, which would nullify any network request reductions that I'm trying to accomplish.
Is each session state mutation accompanied by a synchronous database request, or are all session state changes persisted at one time during the ASP.NET request life cycle?
Sessions are persisted at the end of each ASP.NET request after the ReleaseRequestState application event - and not on session data change.
Related
After a user has initially established session with ASP.NET, with each subsequent HTTP request how much of StateServer session objects are immediately and automatically fetched and deserialized? For example:
Are ALL session objects fetched the moment the request is received and session re-established, or...
After session is re-established are session objects fetched and deserialized individually as each request to HttpContext.Session["..."] is made?
The answer has a HUGE impact on how I can use session. For example, if I have pre-fetched a significant amount of user data into session, and the StateServer session is completely deserialized upon each HTTP request, then I will experience a noticeable performance hit. If however the pre-fetched user data is only deserialized when I request specific session keys, then for me there is no worry.
UPDATE
After marking an answer to this question, I discovered that ASP.NET with AppFabric Server 1.1 has an option to have session restored on-demand rather than all-at-once. This is controlled by useBlobMode in your web.config.
Session loads all of the user Session information when the page is first loaded. It then persists the users Session information back to the store after the page is done processing.
You can get a better understanding via MSDN on custom state store implementations.
This is a major reason that you're supposed to use Session as rarely as possible because it is expensive to deal with (both in the transporting to and from the data store and the holding of the data in memory for the lifetime of the page request).
I'm using the ASP.NET session state server for one of my websites. I put a user object in session because it is used a lot.
Consider the following code fragment:
DoSomething(SessionUser.Me.UserID)
DoSomeMore(SessionUser.Me.UserName)
SessionUser.Me is a static property that just does something like:
return (SessionUser)Session["currentuser"];
Now because I access SessionUser.Me 2 times (DoSomething and DoSomeMore) is .NET smart enough to not do 2 roundtrips to the stateserver and deserialize 2 times?
With other words is it equivalent in performance if I just did:
var user = SessionUser.Me;
DoSomething(user.UserID)
DoSomeMore(user.UserName)
?
Session is deserialized from the state server early in the request pipeline (see HttpApplication.AcquireRequestState, and written back to the state server when execution of the page completes (see HttpApplication.ReleaseRequestState).
Thus, you shouldn't incur a performance hit from repeated access.
How, or maybe where, is the session timeout handled when you set SQL Server as state handler in an ASP.NET application?
Is it the .NET framwork who after loading session objects from the DB does a judgement on whether or not the objects are expired, or is it a job on the SQL Server itself that takes care of this? The reason I suspect (or even concidered) the latter possibility, is that the script that created the ASPState mentioned something about a ASPState_Job_DeleteExpiredSessions-element.
If it is so that it is an SQL Server job that cleans up, how often does this job trigger and how does it align with the timeout parameter in web.config?
From the article linked to by Quantum Elf:
SqlSessionStateStore doesn't actively monitor the Expires field. Instead, it relies on an external agent to scavenge the database and delete expired sessions—sessions whose Expires field holds a date and time less than the current date and time. The ASPState database includes a SQL Server Agent job that periodically (by default, every 60 seconds) calls the stored procedure DeleteExpiredSessions to remove expired sessions.
This means that it's the SQL Server that handles expriation and session object purging, and the SQL Job Agent in particular.
The ASP.NET session state timeout is still configured in web.config/machine.config regardless of whether you do state in-process or store it in SQL Server.
Does IIS create the session id when a request is received and where is that saved (client or server)?
How does server recognize that the request is coming from the same user/session?
The answer to your first question is Yes -- if sessions are used, and Both.
A cookie is a short bit of text passed back and forth between client and server with every request/response.
IIS generates a session id, saves it, and any associated data, and passes the in a cookie to the client (browser).
When the client makes another request, it sends the cookie, containing the sessionID back to the server. The server can then look at the cookie and find the session (and the associated data) which is saved on the server.
In ASP.net, there are multiple places for the session to be saved, but it's always within the server infrastructure.
The default is the memory of the IIS Process. This means: if you reset IIS (or the whole PC) or even just the application pool within IIS, all sessions are deleted, and the session data is lost forever. Also, if you have a LOT of sessions and store a lot of data in each session, the process will require a lot of memory, which can be a problem. This is called "In-Proc" Sessions.
The main alternative is a SQL Server Database. That way, sessions are kept even after a restart and it does not really matter how large each session is. The main downside is the added latency: Fetching data from a database is slower that the In-Proc solution of course.
There are also some other methods how to store sessions (including the option to write a completely new session provider), but the two common ones are "The Memory of the Server" and "A MS SQL Database".
I'm using ASP.NET, with session state stored out of process in SQL Server. When a page request begins, are the entire contents of a user's session retrieved from the DB, deserialized, and sent to the ASP.NET process in one fell swoop, or are individual objects transferred to the ASP.NET process only as needed?
Basically, I have a page that stores some large objects in session, and it's hard for my application to determine when the data can be disposed. If the data is only pulled out of the DB when it's used then there isn't an issue; if the entire session state is chunked to ASP.NET for each page request, I might have a performance issue.
It's all in one go. The session object is recreated from the store at the beginning of the request. It lets ASP.NET work the same way no matter what the underlying store is.
You can find the gory details here.