MaxConcurrentRequestsPerCPU and Asynchronous Requests
I am using C# 4.0, ASP.NET MVC 3 and IIS 7.0. I am little confused about asynchronous requests in IIS 7. I have read t开发者_JS百科his article and several forum/blog posts, but didn't find the answer yet. Here is my question,
I have an application that call many remote services. Many of them respond very slowly. So using AsyncController will free up my application threads. But in the above article Thomas is saying that IIS 7 uses Maximum Concurrent Requests Per CPU instead of Maximum Concurrent Threads Per CPU. So I think freeing up threads using AsyncController will not effect the overall application stability, because we are now request specific instead of thread specific. So if I have 6000 concurrent requests, using AsyncController will only allow 5000 requests to execute concurrently.
Update: I just want to ask that whether switching to AsyncController makes any difference?
Yes, async actions will make better use of CPU/memory resources for long running tasks that are network bound. This is, after all, the exact reason such a feature was added to MVC. They let you avoid having 1 thread per request being tied up for long periods of time. Threads are relatively expensive in terms of CPU & memory resources to create & maintain.
Sure, IIS is default configured to only allow 5000 async requests to be processed at a time (per CPU) but the blog you link to is pretty clear that this is just an arbitrary number that they picked "because it's big"
If you need to handle more than that and have tested that your server can safely handle more, then by all means tweak the IIS configuration to increase the limit. It's a good idea to have such a limit in place to reduce the impact of DOS attacks, etc - beyond the point where you've actually tested your server's ability to handle a load, you should let IIS do it's thing and return a "too busy" error
精彩评论