在 aspx-page 中使用线程发出网络请求
我有一个 aspx 页面，它接受一些输入并发出请求：
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(string.Format("{0}?{1}", strPostPath, strPostData));
request.Method = "GET";
request.Timeout = 5000; // set 5 sec. timeout
request.ProtocolVersion = HttpVersion.Version11;
try
{
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
/do some with response
}
catch (WebException exce)
{
//Log some stuff
}
问题是这个函数被使用了很多次。
在单独的线程中发出每个请求是否有任何优势？具体会是什么样子？
I have an aspx-page that takes some input and makes a request:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(string.Format("{0}?{1}", strPostPath, strPostData));
request.Method = "GET";
request.Timeout = 5000; // set 5 sec. timeout
request.ProtocolVersion = HttpVersion.Version11;
try
{
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
/do some with response
}
catch (WebException exce)
{
//Log some stuff
}
The thing is that this function is used a lot.
Is there any advantage to make every request in a separate thread and exactly how would that look like?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 ASP.NET 中使用多线程时必须考虑一些问题。
首先，您必须认识到每个 ASP.NET 页面请求都到达不同的工作线程。已经有很多线程在使用了！
其次，在您的示例中，页面似乎必须等待响应才能将 HTML 返回到浏览器。使用多个线程不会节省任何时间，因为页面仍然需要等待结果。
您可能获得的一个好处来自于上述两个问题的结合。如果您的页面因等待网络请求的响应而被阻塞，则意味着您在等待响应时阻塞了工作线程。该工作线程可以为另一个页面请求提供服务。这可能会影响可扩展性。
如果可伸缩性成为问题，您可以使用异步页面来缓解这种情况下的问题。使用此模型，当页面开始等待 Web 请求时，页面会将控制权返回给 ASP.NET。然后工作线程可以服务另一个请求。当 Web 请求的响应到达时，页面可以继续处理。与此同时，您宝贵的工作线程不会将时间花在无所事事上。
请参阅：
There are issues you must consider when using multiple threads in ASP.NET.
First of all, you have to realize that every ASP.NET page request arrives on a different worker thread. There are already a lot of threads in use!
Secondly, in your example, it seems that the page must wait for the response before returning HTML back to the browser. You won't save any time by using multiple threads, since the page still has to wait for the result.
The one benefit you might achieve comes from a combination of the above two issues. If your page is blocked waiting on the response from the web request, then that means you're holding up a worker thread while waiting for a response. That worker thread could instead be servicing another page request. This can impact scalability.
If scalability becomes a problem, you can use Asynchronous Pages to alleviate the problem in this case. With this model, when the page starts to wait on the web request, the page returns control back to ASP.NET. The worker thread may then service another request. When the response from the web request arrives, the page can continue processing. In the meantime, your precious worker threads don't spend their time doing nothing.
See:
在单独的线程上执行此操作的优点是，在检索请求时线程不会阻塞。
但是，不建议实际创建线程并执行它；你最终会遇到很多同步问题——什么时候完成以及如何获得结果等。最好使用异步方法（它仍然使用另一个线程），因为它允许您简单地指定一个方法检索到请求后调用。
对于
HttpWebRequest.GetResponse，异步方法是HttpWebRequest.BeginGetResponseThe advantage of doing this on a separate thread would be that your thread wouldn't block while the request is being retrieved.
However, actually creating a thread and executing it is not recommended; you end up with a lot of synchronization problems--when is it done and how will you get the results etc. It is best to use an asynchronous method (which still uses another thread) as it allows you to simply specify a method to be called when the request has been retrieved.
For
HttpWebRequest.GetResponse, the async method isHttpWebRequest.BeginGetResponse