同步HTTP处理程序和异步HTTP处理程序之间的性能差异
同步HTTP处理程序和异步HTTP处理程序之间是否存在性能差异？ IHttpHandler vs IHttpAsyncHandler
为什么选择另一个？
有什么好处？
ASP.NET使用线程池来处理传入的HTTP请求。
调用IHttpHandler时，线程池线程用于运行该请求，同一线程用于处理整个请求。 如果该请求调用数据库或其他Web服务或任何其他可能需要时间的内容，则线程池线程将等待。 这意味着当线程池线程可用于处理其他请求时，它们会花时间等待事物。
相反，当存在IHttpAsyncHandler时，存在一种机制，允许请求注册回调并在完全处理请求之前将线程池线程返回到池。 线程池线程开始对请求进行一些处理。 可能在数据库调用或Web服务或其他东西上调用一些异步方法，然后注册一个回调，以便在该调用返回时调用ASP.NET。 此时，处理HTTP请求的线程池线程将返回到池以处理另一个HTTP请求。 当数据库调用或其他任何内容返回时，ASP.NET会在新的线程池线程上触发已注册的回调。 最终结果是您没有线程池线程等待I / O绑定操作，您可以更有效地使用线程池。
对于非常高的并发应用程序（数百或数千个真正同时用户），IHttpAsyncHandler可以大大提高并发性。 如果您有很长的运行请求（例如长轮询请求），则用户数量较少，仍然可以获益。 但是，在IHttpAsyncHandler下编程更复杂，因此在不需要时不应使用。
除了管理另一个线程之外，没有任何性能差异。
同步更容易编码。 您发送请求并且线程冻结，直到返回响应。 然后，您可以在同一方法中处理响应和错误。 它易于阅读和调试。 如果您在GUI线程中运行此代码，如果您没有快速收到响应，Windows可能会报告您的程序“没有响应”。
如果您不希望线程冻结，请使用Asynchronous。 当后台任务等待HTTP响应时，用户可以继续与程序交互。 然后你必须编写代码来管理后台任务，观察它是否完整，处理错误，将这些错误传递回GUI线程等等。这是一项更多的工作，并且更难以阅读和调试，但最终还是如果做得好，质量更好的产品。
编辑：更正了同步方法冻结线程，不一定是整个程序。