1

We have an ASP.NET app running on a Azure Windows Server 2012 R2 VM with IIS 8. All settings are pretty much default.

Our app runs on two web application. One for the frontend (MVC) and one for the API (Web API). Both use the DefaultAppPool.

Today one Web API request had a SQL server call that didn't return until the timeout (that SQL server was offline). But funny enough, all other calls to our Web API project also seemed blocked after that. We might have about 50 users on our website and maybe 5 users made a call to this blocking method at the same time.

So I'm a bit confused to why all other requests were also blocked. The request to the MVC frontend were not blocked. Even though it's using the same thread pool.

Reading the discussions about thread pools on IIS, I think we should have enough threads to handle a situation like this?

asp.net Thread-pool max threads - clarification?

What am I missing here?

Remy
  • 12,555
  • 14
  • 64
  • 104
  • It is pretty difficult to name the reason without the whole code, it is just too broad and needs some diagnostics / debugging. Seems like there is a synchronization issue. General advice: use `async/await` to avoid blocking calls to database. – Yeldar Kurmangaliyev Jul 13 '17 at 09:14
  • 1
    This question may be similar: https://stackoverflow.com/questions/30057531/why-are-my-requests-to-web-api-being-blocked-by-long-running-controller-code – Yeldar Kurmangaliyev Jul 13 '17 at 09:18
  • Yeah, the async/await makes lots of sense. Unfortunately we use Azure SQL with ReliableSqlConnection and that does not support async / await very well. Nevertheless I'm a bit worried why this happens in the first place. We should have more than enough threads to handle this situation. – Remy Jul 13 '17 at 09:54
  • Ahh, read the question you posted. Could be the issue! Thanks – Remy Jul 13 '17 at 09:56

0 Answers0