如何在 ASP.NET 中等待异步 Web 服务调用的结果以获得最佳性能

发布于 2025-01-03 15:27:54 字数 569 浏览 0 评论 0原文

在 WebForms ASP.NET 站点(IIS、单个应用程序池)中,我调用了 Visual Studio 中引用的冗长的 Web 服务方法作为服务引用 (.NET 4.0)。不幸的是,我必须等待来自网络服务的信息,然后才能向用户提供页面。目前,Web 服务是同步调用的,因此服务器无法重用当前线程来处理其他请求,这会影响性能。

当然,我可以在 Visual Studio 中生成服务引用的异步操作,并调用 BeginGetFoo 而不是 GetFoo,但我仍然必须以某种方式等待 Web 服务的结果。

问题来了。如果我使用 AsyncWaitHandle.WaitOne (如下所示),与我今天使用的同步调用相比,整个应用程序性能会更好吗?

IAsyncResult result = fooSoapClient.BeginGetFoo();
result.AsyncWaitHandle.WaitOne();
var foo = fooSoapClient.EndGetFoo(result);

当然,如果等待可以做得更好,我愿意接受建议。

In WebForms ASP.NET site (IIS, single app pool), I have call to lengthy web service method referenced in Visual Studio as Service Reference (.NET 4.0). Unfortunately I must wait for information from web service before I can serve page to user. Currently web service is called synchronously so server can’t reuse current thread to process other requests which has performance impact.

Of course I can generate asynchronous operations for service reference in Visual Studio and call BeginGetFoo instead of GetFoo, but still I must wait somehow for result from web service.

Here comes question. If I use AsyncWaitHandle.WaitOne (as below) will it be any better in whole application performance terms from synchronous call I use today?

IAsyncResult result = fooSoapClient.BeginGetFoo();
result.AsyncWaitHandle.WaitOne();
var foo = fooSoapClient.EndGetFoo(result);

And of course, if waiting can be done better I am open for suggestions.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

得不到的就毁灭 2025-01-10 15:27:54

您想要使用异步页面。请参阅“邪恶代码:ASP.NET 中使用异步编程的可扩展应用程序”,另ASP.NET 2.0 中的异步页面,讨论 Web 服务和异步任务与 RegisterAsyncTask

You want to use an Asynchronous Page. See "Wicked Code: Scalable Apps with Asynchronous Programming in ASP.NET", also Asynchronous Pages in ASP.NET 2.0, which talks about web services and Asynchronous Tasks with RegisterAsyncTask.

夏花。依旧 2025-01-10 15:27:54

你仍然会霸占线程。一个“安全”的选项是使用 ASP.NET MVC 的异步控制器: http://www.aaronstannard.com/post/2011/01/06/asynchonrous-controllers-ASPNET-mvc.aspx

理想情况下,您不应该在网络请求。让 Windows 服务或其他东西处理长时间运行的任务(可以通过 Web 请求将某些内容放入消息队列或将任务放入数据库来启动)并使用 ajax 或其他东西从客户端进行轮询,然后在以下时间更新用户完成了。

You'd still be hogging the thread. A "safe" option would be to use ASP.NET MVC's async controllers: http://www.aaronstannard.com/post/2011/01/06/asynchonrous-controllers-ASPNET-mvc.aspx

Ideally though, you shouldn't do long running things on a web request. Have a windows service or something process the long running task (that could get kicked off by a web request dropping something on a message queue or putting a task in a database) and poll from the client using ajax or something and then update the user when it's done.

洋洋洒洒 2025-01-10 15:27:54

如果重构您的代码是不可接受的,因此您无法遵循@John Saunders 的答案,那么您唯一能做的就是增加应用程序的线程数。这将使您能够更好地扩展,但在某些时候,它的回报将会递减,并且您将开始损害性能。更重要的是,如果您没有用户在请求队列中等待(即服务器上每个核心的并发用户数超过 25 个),您无需执行任何操作。 Web 服务器中的异步编程仅有助于提高可扩展性,但对单个用户的实际性能没有帮助。

If refactoring your code is not acceptable so you cannot follow @John Saunders's answer then the only thing you can do is increase the number of threads for the application. This will allow you to scale better but at some point it will have diminishing returns and you will start hurting the performance. What is more if you do not have users waiting on the request queue (i.e. more than 25 simultaneous users per core on your server) you don't need to do anything. Async programming in the web server helps only with scalability but not actual performance for a single user.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文