1

I have a a standard ASP.NET (Web Forms) application running on IIS8 and receiving complaints that sometimes it takes to the website too much time to process requests.

After deep investigation and logging I've figured out that delays take place wherever after the end of PreRequestHandlerExecute event in my last HTTP module and before ProcessRequest event in my HTTP handler.

As far as I understand I don't have any code in between and this part of the pipeline is absolutely managed by IIS and ASP.NET framework. I've also seen that Module and Handler processing thread ID changes when delays take place.

I've read tons of docs and haven't got closer to the resolution :(

What can be reason for these delays?

Thanks in advance

Skatrix
  • 129
  • 1
  • 12
  • Does your handler implement [IRequiresSessionState](https://msdn.microsoft.com/en-us/library/system.web.sessionstate.irequiressessionstate(v=vs.110).aspx)? Delay could be due to blocking/lock on the session data. – John Wu Feb 13 '17 at 19:57
  • John, thanks for your answer. My handler indeed implements and uses Session. Is there any solutions for these locks? – Skatrix Feb 20 '17 at 08:10
  • I added an answer to address the locks, but it sounds like that is not your issue. – John Wu Feb 20 '17 at 21:27
  • Have you tried [precompiling the site](https://msdn.microsoft.com/en-us/library/bb398860.aspx) to see if that helps? Perhaps a portion of the load time has to do with automatic first-time compilation. – John Wu Feb 20 '17 at 21:28

1 Answers1

1

Your site isn't slow: it is waiting.

ASP.NET only allows one thread to execute per session ID. If a user has two tabs open and and tries to submit two web requests with the same session ID, the second thread will block until the first completes.

See this question for discussion and a few different solutions: I just discovered why all asp.net websites are slow.

The easiest answer is... If the handler only needs read access to session variables, implement IReadOnlySessionState instead of IRequireSessionState. This will allow the handler to execute concurrently at least with itself.

Of you can use Microsoft's brand new async session state module, recently released. It should work. If it does, be sure to answer this question.

Community
  • 1
  • 1
John Wu
  • 50,556
  • 8
  • 44
  • 80
  • Thanks for your answer, but unfortunately it's not the case :(. I'm aware about "single-session-per-browser" limitation, but delays I see don't refer to the second request blocked by the first one, but to the first request getting delay wherever in IIS. – Skatrix Feb 20 '17 at 19:56
  • BTW, while investigating this issue on the server side I noted a few additional points. First of all on the server I see that ID of the thread handling the request changes after delay. I tried to enable Failed Request Tracing log, but for some reason I get incomplete log. In request summary I see that some request took 40 seconds to be processed, but the log only display detailed log just until the point the delay begins (GENERAL_READ_ENTITY_START log entry). And then log breaks... :(( – Skatrix Feb 20 '17 at 20:00