Just installed IIS Express 7.5 and am trying to debug a concurrency issue in an ASP.NET MVC 3 application. I don't however seem to be able to get the web server to process requests concurrently, they just get executed one by one.
I'm running Apache Bench to simulate a concurrent load but it's just getting queued up.
Anybody got any ideas?
Thanks.
If you are using sessions and reusing the Session ID for your concurrent requests, ASP.NET will queue the requests because it needs an exclusive lock on the session for each request.
Taken from http://msdn.microsoft.com/en-us/library/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.
You don't have anything odd in your web.config for the app do you such as settings for maxConcurrentRequestsPerCPU, maxConcurrentThreadsPerCPU?
http://msdn.microsoft.com/en-us/library/dd560842.aspx
Related
In Jmeter, I have a thread group with 20 http sampler, added HTTP Cookie manager and session is been handled through JSESSIONID.
When I run a script for multiple users with > 10 threads, the first few threads are running properly, thereafter some HTTP samplers of other threads are failed with an error (on the web page): "Your Session is logged out. Please close current window and try login to the application once again."
When I did further analysis, different JSESSIONIDs are passed in between within the same thread.
Please have a look on how a different session id passed for the samplers in same threads and provide a solution for this.
Note: When I run this for a minimal number of users like 2, I don't get this issue.
Two options available
If you are using URL redirects And come back to main url,you may get different jsessionid And its depend on your server configuration you have,you need to use proper regular expression to extract the session and to bind in next call
If you are using same credentials for various threads And if your server config don't have the capability to manage it you may get various jsessionid
what could the cause behind dropping of authentication cookie (.ASPXAUTH) intermittently in an MVC3 app?
I checked the size of cookie which seems to be around 2kB.
It flows without any issues during login and performing few actions in site. but after performing one specific action (where I am returning a pdf file from server and cookie in untouched there) it drops for a very few users.
Could there be any other reason behind user being logged out of system after certain action?
I just have got info that cookie can be dropped if your applcation is being recycled by the server. There are three conditions that would cause your application pool to be recycled by the server. 1. Over CPU usage. 2. Over memory usage. 3. No http calls for 20 minutes.
I have been given a requirement to persist user data once the user has authenticated initially. We don't want to hit the database to look up the user every time they navigate to a new view etc...
I have a User class that is [Serializable] so it could be stored in a session. I am using SQL server for session state as well. I was thinking of storing the object in session but I really hate doing that.
How are developers handling this type of requirement these days?
Three ways:
Encrypting data in cookies and sending it to client, decrypting it whenever you need it
Storing it server side by an Id (e.g UserId) in Cache, Session, or any other storage(which is safer than cookie).
Use second level caching strategy if you used an ORM
Assuming your user object is not huge and does not change often i think it is acceptable to store it in the session.
Since you already have a sql server session you will be making SP calls to pull/push the data already and adding a small object to that should have minimal perf issues compared to other options like persisting it down to the client and sending it back on every request.
I would also consider the server a much more secure place to keep this info.
You want to minimize the number of times you write to the session(request a lock) when it is stored in sql as it is implemented in a sealed class that exclusivity locks the session. If any of your other requests in this session require write access to the SQL session they will be blocked by the initial request until it releases the session lock. (there are some new hooks in .NET 4 for allowing you to change the SessionStateBehavior in the pipeline before the session is accessed)
You might consider a session state server (appfabric) if perf of your SQL session store is an issue.
My challenge is the following. I'd like to uphold the Post/Redirect/Get pattern for posted forms, but after the redirect I still want to show the state of the form in case of invalid fields. This information can be passed by storing it in session quite easily.
However these sites usually run on multiple webservers behind a load balancer, which are configured NOT to be sticky. There is also no shared session state on purpose.
To use local session state on the webservers would be preferrable for scalability, but to do that you need sticky sessions. Sticky sessions are however a hindrance to the people who manage the servers, because after removing some servers from the load balancer to do a release, they still have to wait some 10 to 15 minutes before all sessions have ended. Without stickiness it's almost instantaneously.
What would be really cool is if we could make the session sticky for just one single subsequent request after a POST or REDIRECT. Or even have total control over when to enable or disable stickiness from code.
Does anyone know if this behaviour is possible? By settings a certain cookie perhaps? Or some http header?
Few ideas:
Central cache server
save it to a cache server (prefered redis) with expiration
redirect to the get action with a parameter in the url. Using this parameter restore the model.
State in the url
if the model is small You can save it as parameters in the url.
This is a bit of a throwback question, and probably relatively fundamental, but I'm at a loss.
How does IIS manage Classic ASP session state?
We have an app that stores user information in session, and when many users are using the app, it seems to be recycling session for users, even though the "expire period" has not elapsed.
We suspect that when a certain amount of memory has been used for the session state, it begins to recycle the oldest session objects or something like this.
If this is correct, is there some way to control for it with the existing application code?
Thanks!
ASP sessions are stored as simple in memory COM objects when the process hosting the ASP application are terminated so will all the sessions.
ASP does not "recycle" active sessions. However there are number of other circumstances which can affect ASP sessions.
Application Pool Idle Timeout
One phantom reason "Sessions" appear to timeout prematurely is because the "Sessions" in question are just under test during development. Hence whilst the developer is examining the content of a page or reviewing some code no further requests hit the site since its not actually a live site.
In IIS manager open the properties of the pool in which your ASP application runs. Take a look at the Performance tab. The Idle Timeout will default to 20 minutes. Hence if you have specified a session timeout of say 60 minutes and you are "testing" that timeout you actually discover your session has timed-out in 20 minutes. The lack of activity has killed the application pool.
Application Pool Recycling
IIS may recycle the application pool in which the ASP application is running in. Recycling means that the existing set of processes currently hosting the ASP application no longer accept new requests. New requests go to a new set of processes and the older processes will terminate when they have completed their outstanding requests.
There are a whole host of different settings and criteria that can be configured that trigger the recycling of an application pool. Take a look at the Recycling tab of the pool properties dialog.
If you think that there may be an excessive demand for memory then the Memory recycling section may indicate a cause.
Web Garden
An Application Pool can contain multiple processes to run the same set of applications. Back on the performance tab note the Web Garden section at the bottom. By default this is set to 1. However multiple worker processes will play havoc with ASP sessions. As noted above ASP session are simple in-memory COM objects. If subsequent requests for a specific session are dished out to different workers one worker will not have access to the session object that the other has.
Session.Abandon or Session.Clear
Logic bugs can sometimes be the cause of sessions apparently disappearing. Calling the above methods at an inappropriate point in a sessions life can cause a problem.
I have experienced the same thing. Session seems to be emptied of the data, meaning that no variables is no longer stored in the session, but since the session exists, On_SessionStart doesn't trigger.
Gives you a headache if you initialize data for a visitor that you later on depends on...
I have considered this a bug that no one seems to know about, and haven't found a solution to it. It seems related to memory-usage, as you point out, and the solution seems to be to make sure you don't have any leaks.
Implement object-caching in classic ASP memory-leaking
This issue for me turned out to be the number of worker processes under the Performance tab. It was set to 2 for some reason. We set it back to 1 and the issue went away.