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.
Related
If I have sessions backed by SQL Server and run a command sequence like
HttpContext.Current.Session['user']
HttpContext.Current.Session['user']
Will this make 2 requests to the session DB table to fetch the value, or does asp.net do anything special with the Session object to prevent multiple DB hits?
Definitely YES.
I have SQL server session state setup and i ran Profiler on it. And could clearly see optimized DB calls.
If fact there are optimizations for getting multiple session items in one shot.
Like the below code will also result in SINGLE optimized set of calls (Note: Its not a plain single DB call to get session item)
HttpContext.Current.Session['user']
HttpContext.Current.Session['userTwo']
NOTE: Tested in .NET 4
You can implement your own session state provider if you need.
http://msdn.microsoft.com/en-us/library/ms178587.aspx
I have inherited a fix on a classic ASP application where we want to store some user session-specific data to persist across page loads/their session, and need a bit of a refresher.
In the past I have simply used Session variables - ie. Session("SomeVar") = SomeVal.
In IIS on the production box, I noticed that ASP / Session Properties / Enable Session State = false. Setting this to True allowed me to successfully begin using session variables.
I don't want to consume any more resources than necessary on the server. In the past, I believe that I was under the delusional misconception that session variables in classic ASP were stored on the client side. Revisiting this now - the data is retained on the server side.
The string I am saving is a GUID, for roughly 3000 connected clients.
What kind of server impact am I looking at if I implement this, and would using client-side cookies be a better option?
Lets analyse this a bit, a GUID takes about 40 characters as a string hence in Unicode thats 80 bytes, lets call it 100 bytes. 100 * 3000 = 300KB. Can server spare 300K for this? I think the server already in trouble if the answer were no.
However there are other impacts to enable session state. When sessions are enabled ASP adds its own cookie to the client which in size terms is probably equivalent to the one you would need if you were storing your GUID as cookie instead of in the session. Its worth noting that this session ID stored in the cookie uses an algorithm which some say is more predictable (I haven't got any evidence of that myself). Hence if you are using the GUID as some form of authorization then storing the GUID as cookie directly may be better.
There is a further significant change that happens when Session state is enabled. ASP requests from a client must be processed serially, the server will not process multiple requests from the same client in parallel. This is because the Session object is single threaded and since each request from a client needs access to it the requests cannot be processed at the same time.
That last point could have significant impact on the existing behaviour and performance that a client sees especially if AJAX techniques, multiple IFrames or other techniques which result in simultaneous ASP requests being sent to the server are being used.
Hence for the requirement you have my choice would be to store the GUID in a cookie and leave session state turned off.
Multiple servers/server farm? If so you might run into trouble using Session if you load balancer is not set to be "sticky" and send you to the same server each time. Can me a real headache to debug so becareful.
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.
Let's imaging there are 2 pages on the web site: quick and slow. Requests to slow page are executed for a 1 minute, request to quick 5 seconds.
Whole my development career I thought that if 1st started request is slow: he will do a (synchronous) call to DB... wait answer... If during this time request to quick page will be done, this request will be processed while system is waiting for response from DB.
But today I've found:
http://msdn.microsoft.com/en-us/library/system.web.httpapplication.aspx
One instance of the HttpApplication class is used to process many requests in its lifetime. However, it can process only one request at a time. Thus, member variables can be used to store per-request data.
Does it mean that my original thoughts are wrong?
Could you please clarify what they mean? I am pretty sure that thing are as I expect...
The requests have to be be processed in the sequential order on the server side if the both request use the same session state with read/write access, because of asp.net session locking.
You can find more information here:
http://msdn.microsoft.com/en-us/library/ie/ms178581.aspx
Concurrent Requests and Session State
Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the # Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.
Your original thoughts are right, and so is the documentation. The IIS worker process can spawn many threads, each with their own instance of the HttpApplication class.
ASP .NET will host multiple AppDomains for your web application under a single worker process (w3wp.exe). It may even share AppDomains for different web applications under the same worker process (if they are assigned to the same app pool).
Each AppDomain that ASP .NET creates can host multiple HttpApplication instances which serve requests and walk through the ASP .NET lifecycle. Each HttpApplication can (as you've said) respond to one request at a time.
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.