同步 HTTP 处理程序和异步 HTTP 处理程序之间的性能差异
同步 HTTP 处理程序和异步 HTTP 处理程序之间有性能差异吗？ IHttpHandler 与 IHttpAsyncHandler
为何选择其中之一？
有什么好处？
Is there a performance difference between Synchronous HTTP Handler and Asynchronous HTTP Handler?
IHttpHandler vs IHttpAsyncHandler
Why choose one over another?
What are the benefits?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ASP.NET 使用线程池来处理传入的 HTTP 请求。
当调用 IHttpHandler 时，将使用线程池线程来运行该请求，并使用同一线程来处理整个请求。如果该请求调用数据库或其他 Web 服务或任何其他可能需要时间的内容，则线程池线程将等待。这意味着线程池线程在可用于处理其他请求时花费时间等待事物。
相反，当使用 IHttpAsyncHandler 时，存在一种机制允许请求注册回调并在请求完全处理之前将线程池线程返回到池中。线程池线程开始对请求进行一些处理。可能会在数据库调用或 Web 服务或其他内容上调用一些异步方法，然后注册一个回调供 ASP.NET 在该调用返回时调用。此时，正在处理该 HTTP 请求的线程池线程将返回到池中以处理另一个 HTTP 请求。当数据库调用或其他任何返回时，ASP.NET 会在新的线程池线程上触发已注册的回调。最终结果是您没有线程池线程等待 I/O 绑定操作，并且您可以更有效地使用线程池。
对于非常高并发的应用程序（数百或数千个真正同时存在的用户），IHttpAsyncHandler 可以提供并发性的巨大提升。对于较少数量的用户，如果您有很长时间运行的请求（例如长轮询请求），仍然会有好处。但是，IHttpAsyncHandler 下的编程比较复杂，因此在不需要时不应使用。
ASP.NET uses the thread pool to process incoming HTTP requests.
When an IHttpHandler is called, a thread pool thread is used to run that request and the same thread is used to process the entire request. If that request calls out to a database or another web service or anything else that can take time, the thread pool thread waits. This means thread pool threads spend time waiting on things when they could be used to process other requests.
In contrast, when an IHttpAsyncHandler, a mechanism exists to allow the request to register a callback and return the thread pool thread to the pool before the request is fully processed. The thread pool thread starts doing some processing for the request. Probably calls some async method on a database call or web service or something and then registers a callback for ASP.NET to call when that call returns. At that point, the thread pool thread that was processing the HTTP request is returned to the pool to process another HTTP request. When the database call or whatever does come back, ASP.NET triggers the registered callback on a new thread pool thread. The end result is you don't have thread pool threads waiting on I/O bound operations and you can use your thread pool more efficiently.
For very high concurrency applications (hundreds or thousands of truly simultaneous users), IHttpAsyncHandler can provide a huge boost in concurrency. With a smaller number of users, there can still be a benefit if you have very long running requests (like a Long Polling request). However, programming under the IHttpAsyncHandler is more complicated, so shouldn't be used when it isn't really needed.
除了管理另一个线程之外，没有任何性能差异。
同步更容易编码。您发送请求，线程将冻结，直到返回响应。然后您可以用相同的方法处理响应和错误。它很容易阅读和调试。如果您在 GUI 线程中运行此代码，如果您没有快速收到响应，Windows 可能会报告您的程序“没有响应”。
如果您不希望线程冻结，请使用异步。当后台任务等待 HTTP 响应时，用户可以继续与程序交互。然后你必须编写代码来管理后台任务，观察它何时完成，处理错误，将这些错误传递回 GUI 线程等。这需要更多的工作，并且更难以阅读和调试，但最终如果做得正确，产品质量会更好。
编辑：更正了同步方法冻结线程，而不一定冻结整个程序。
There's no performance difference aside from managing another thread.
Synchronous is easier to code. You send the request and the thread freezes until the response is returned. Then you can handle the response and errors in the same method. It's easy to read and debug. If you run this code in your GUI thread, Windows may report that your program is "not responding" if you don't receive a response quickly.
Use Asynchronous if you don't want your thread to freeze. The user can continue to interact with the program while a background task waits for the HTTP response. Then you have to write code to manage the background task, watch when it is complete, handle errors, pass these errors back to the GUI thread, etc. It's a bit more work, and a lot harder to read and debug, but ultimately a better quality product if it's done properly.
Edit: Corrected that synchronous methods freeze the thread, not necessarily the whole program.