我应该使用 HttpResponse.End() 来实现快速网络应用程序吗？
HttpResponse.End() 似乎抛出根据 msdn 的异常。现在我可以选择返回一个值来表示结束线程（它只深入 2 个函数）或者我可以调用 end()。
我知道抛出异常的速度明显慢 （阅读 C#/.NET 测试的评论）所以，如果我想要一个快速的 Web 应用程序，当不调用它非常容易时，我是否应该考虑不调用它？
-编辑-我确实在某些函数和类的构造函数中进行了函数调用，以确保用户已登录。因此，我在足够的地方调用 HttpResponse.End()，尽管希望在常规站点使用中它不会经常发生。
HttpResponse.End() seems to throw an exception according to msdn. Right now i have the choice of returning a value to say end thread (it only goes 2 functions deep) or i can call end().
I know that throwing exceptions is significantly slower (read the comment for a C#/.NET test) so if i want a fast webapp should i consider not calling it when it is trivially easy to not call it?
-edit- I do have a function call in certain functions and in the constructor in classes to ensure the user is logged in. So i call HttpResponse.End() in enough places although hopefully in regular site usage it doesn't occur too often.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只需使用 Response.End 即可。在为了性能而编写代码之前，先为了可维护性而编写代码。
此外，对于网络应用来说重要的性能衡量标准是可扩展性。也就是说，您不应该问“我可以多快处理这个单个请求”，而应该问“我可以同时处理多少个请求？”。
异常不会影响您的可扩展性，从总体上看，单个请求多花几微秒没什么大不了的：记住网络往返至少 50 毫秒：另外 100 微秒是噪音。
Just use
Response.End. Write your code for maintainability before you write it for performance.Besides, the performance measure that matters for web apps is scalability. That is, you should not be asking "how fast can I process this single request", but "how many requests can I process at the same time?".
Exceptions do not affect your scalability, and in the grand scheme of things, an extra couple of microseconds on a single request is nothing: remember it'll be at least 50 milliseconds in network roundtrip: another 100 microseconds is noise.
您可以使用 HttpResponse.Flush 将数据推送到客户端，而不是完全终止请求，从而避免引发潜在的异常。
注意：调用 Response.End 时并不总是抛出该异常，只有在您提前结束请求时才会抛出该异常。
You could use HttpResponse.Flush to push data to the client instead of terminating the request completely, avoiding the potential exception being thrown.
Note: That exception is not always thrown when Response.End is called, only when you prematurely end a request.