And also is a paroxysmal, there is a user complaints slow, you visit is very fast, local and reproduce not come out? You're lucky to have visited the blog park today, and maybe there's an answer you want--if your site dynamically processes pictures or other non-web resources that would otherwise not be dynamically processed. Didn't think of it, this is the trouble of the session!
Our company has been visiting a certain site has been very large, a few years ago has found that customers often complained that the problem is very slow, and we have been in the investigation and resolution. From line problems, to database connection leaks, to database deadlock, indexing, and program optimization issues, we've all looked up and solved them. However, the problem is always there. For example, in the IIS log, you will often see time-taken greater than 10 seconds of access. And recently our KPI asked to solve this problem, had to, once again embark on this difficult investigation trip.
The reason is difficult, because this phenomenon is almost impossible to reproduce locally, one is that the phenomenon is paroxysmal, the second is the amount of local access or data is not large enough. We have also tried to load the server's database locally and then replay the server's IIS log file, and the result is that the Time-taken in the IIS logs is occasionally found to be longer, but the local server performance is not as good as the online server, for example, Io is very far away, So I always say I don't know what the problem is. The online server is also not convenient to be used as a dump of the form to find: the first is because of a dump on the line, the site will be in a few minutes to lose the response, so that our customer service phone will be blown; another reason is the problem of the paroxysmal, we can not always stare at performance, and then in the moment of the problem to do dump. Again, the performance is not visible, because the response time is very long and the responses around it are particularly fast. Inevitably, we can just cram some debugging and log code into the code, hoping to get some useful information.
At the very beginning, we thought the most probable cause was a database block, such as a certain access lock on a database object (such as a table or a few lines), if you visit a particular page at this time, it may be slower. A heap of code is crammed into the database layer, which outputs the current access statements for all database connections, the total duration of the connection, and the current stack of those connections to the file when there is a large number of database connections, or when a particular database connection time is particularly long. At the same time, we also opened the SQL Profiler to monitor the database, recording the duration over 1 seconds. After a day's running, however, nothing has been recorded, but the IIS log still has more than 10 seconds of access during that time. At this time, we realize that we may be in the wrong direction.
Then we start to plug another piece of code: a IHttpModule. This module simply intercepts all events in the full lifecycle of each page access, such as BeginRequest, Preauthenticaterequest, and so on. At the same time, set a timer at the start of the beginrequest and an event every second to record the current stack in all threads collected by this module during this visit. Finally, in EndRequest, if the access time exceeds 5 seconds, all previously intercepted information is exported to the file. This suddenly becomes a very clear question, for example, the following output (fragment) is a very typical case:
#Steps:
#Fields: Date Time ThreadId Stepname
#---------------------------------------------------
2009-07-09 16:48:01.752 0024 beginrequest
2009-07-09 16:48:01.752 0024 AuthenticateRequest
2009-07-09 16:48:01.752 0024 Postauthenticaterequest
2009-07-09 16:48:01.752 0024 AuthorizeRequest
2009-07-09 16:48:01.752 0024 Postauthorizerequest
2009-07-09 16:48:01.752 0024 Resolverequestcache
2009-07-09 16:48:01.752 0024 Postresolverequestcache
2009-07-09 16:48:01.752 0024 Postmaprequesthandler
2009-07-09 16:48:06.284 0007 AcquireRequestState
2009-07-09 16:48:06.284 0007 postacquirerequeststate
2009-07-09 16:48:06.284 0007 PreRequestHandlerExecute
2009-07-09 16:48:06.284 0007 endrequest
#---------------------------------------------------
#End of steps.
In other words, after postmaprequesthandler, there is a long wait time before acquirerequeststate. The stack on the back of this report is strange: Thread 7 starts at the first screenshot and ends up blank! Even in other reports, this thread has been assigned to work on other pages (the call in the stack clearly indicates the code for another ASPX page). As a result, Google's two keywords, "Postmaprequesthandler" and "acquirerequeststate", found another victim of a similar encounter abroad:
http://forums.iis.net/t/1147300.aspx
The landlord is an ASPX page with several IFRAME inside, and each iframe is an ASPX page that accesses the same Web application. The phenomenon is the IFRAME inside the page will be jumped out, especially these pages are relatively slow time. As I have intercepted here, it is also a long blank time between the Postmaprequesthandler event and the acquirerequeststate. After that, I found this post:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg= Microsoft.public.dotnet.framework.aspnet&mid=7f56033f-caac-47c2-bd9c-95512aa14b47
Originally, the current page will not continue until the previous page with SessionID has been processed before acquirerequeststate. The root cause is: The same SessionID below the session object should not be written at the same time, otherwise it will be all messed up, the principle and multithreading competition is the same. So in design, the same SessionID page (or IHttpHandler) is executed sequentially.
Well, here comes the truth again! (There are other problems, there will be a time for the next one) in our system, for special reasons, The output of the picture we will be processed through ASP.net, such as adding some appropriate cache tags, and even dynamically generating picture output (surprisingly, the total time of this dynamic output is less than 100 milliseconds, so do not say that dynamic generation is a bad implementation). However, due to the lack of special handling, asp.net the underlying view that these accesses need to write to the session, and then hang before AcquireRequestState, waiting for the last time the SessionID access ended. It can be imagined that many pictures will lead to queues, or even a long line of teams. If you access the next page before the queue ends and the system does not lose the previous queue, the visit will be long. So how do you do it? In a second track, found the exact statement:
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Note the following passage:
Concurrent Requests and Session state
Access to asp.net the session ' is exclusive ' session, which means this if two different users make concurrent requests , access to the separate session is granted concurrently. However, if two concurrent requests are for the made session (by using the same same value), the ETS exclusive access to the session information. The second request executes only has been finished. (The second session can also get access to the exclusive lock on the information is freed because the "I" exceed s the lock time-out.) If theenablesessionstate value in the @ Page directive be set to ReadOnly, a request for the read-only session information Does not result in a exclusive lock on the session data. However, read-only requests for sessions data might still have to wait for a lock set by a Read-write request for session D ATA to clear.
In other words, for a page, we can simply set enablesessionstate= "false" in the <% @Page%> of the aspx, or enablesessionstate= "ReadOnly", Can alleviate the symptoms of this problem. The previous setting will prevent access to the session, and the latter setting can only allow read-only access (you cannot write to the session). Just as we mentioned in the IHttpHandler, the part of the image processing is not required to write to the session, but it needs to read the session (depending on the status of different, and need to get some special information), so you can take the above measures to solve the problem.
The above references do not show how to set the IHttpHandler of the page, which I would specifically say. For a custom implementation of the IHttpHandler interface class, as long as the implementation of ireadonlysessionstate, you can achieve enablesessionstate= "ReadOnly" effect. Also, if IRequiresSessionState is not implemented, it is equivalent to the effect of enablesessionstate= "false".
Attention: This article says, not that you have no use in the code to Session,asp.net will not scan your code to see if there is access to the session, or the first time you visit the session will not be added lock. ASP.net is the first to apply for this lock before the AcquireRequestState event--as long as your page is not set enablesessionstate= "false" or enablesessionstate= "ReadOnly", Or your IHttpHandler implements the IRequiresSessionState but does not implement the Ireadonlysessionstate interface. There are a lot of students in the reply that "as long as I do not have to session not on the line?" "or" I never use the session, "It is completely wrong to think, can only say that you do not understand the mechanism behind this, or even asp.net life cycle is not very clear. The reason why asp.net locks up before your page code starts is to ensure the integrity of the entire environment and avoid partial execution. Of course, as mentioned in some of the references above, you can write a sessionprovider yourself without doing any lock work, but there is certainly a risk of uncertainty, which can only be borne by yourself and more difficult to reproduce and debug.
PostScript:
There may be a lot of people who know what the session is, There are also many people who know the life cycle of asp.net, such as a search "Postmaprequesthandler acquirerequeststate", will come out a lot of Chinese pages to introduce the HttpApplication class have what events, And life cycle, and so on. When it comes to the session will cause special circumstances site performance problems, it seems to me this is really the first article in the Chinese domain. Of course, this problem may be biased, because generally people will only deal with ASPX pages do not process images, and even the use of ASPX pages to dynamically output the picture is less opportunities, the English seems to be only the only one of the comrades mentioned in the article. &NBSP
However, there is a very common scenario that is affected by this problem, which is "Authenticode". If the authentication code generation is slow, and the client browser chooses a long connection and the server accepts a long connection, it may affect the speed at which the next page is accessed before the output Authenticode is complete. In turn, we can often experience that the verification code out of the speed is always very slow, always "bounce" out, especially when the current page is particularly complex, it seems that the page does not load the total will not appear verification code. I guess the question I'm talking about is one of the reasons. &NBSP
However, the problem with verification code is not particularly good, because in order to avoid the problem of information leakage, the answer to the captcha is usually in the session. And the usual design is a visit to the code picture, will be the answer to the verification code written in the session. Therefore, unfortunately, the solution mentioned in the article is not workable, at least not directly to the line. Is the problem hopeless? Yes, of course it is. How to save? Ah, then you have to use your own brains, I here is a point to stop.
