任务和并行编程 ASP.Net
是否可以使用 .Net 中的 TPL 库来包装调用？
我想做这样的事情
Task t1 = Task.Factory.StartNew(() => {dynamic result = FacebookApp.Get("me/videos/uploaded",parameters); });
但我收到 HttpContext 错误，我假设这是因为 FacebooApp.Get 方法在内部使用它。
如何将对 FB API 的调用包装到任务中以在服务器上并行运行？
我忘了提及我正在使用 Facebook C# SDK，因此 FacebookApp.Get
EDITED
我一直在 TPL 库上观看一些pluralsight 视频，并采用了下图所示的模式。正如您所说，主线程来自 Create Controller 本身，但我仍然需要生成 4 个单独的网络任务来并行执行网络调用。我通过不让第四个任务中调用的函数完全不依赖 HttpContext 来修复 HttpContext 错误。
现在对我来说，最终结果是性能更高的方法调用，正如并行编程所承诺的那样。
Is it possible to wrap a call using the TPL Library in .Net?
I want to do something like this
Task t1 = Task.Factory.StartNew(() => { dynamic result = FacebookApp.Get("me/videos/uploaded", parameters); });
But I get an HttpContext error, I am assuming this is because the FacebooApp.Get method is using this internally.
How can I wrap calls to the FB API into tasks to run in parellel on the server?
I forgot to mention I am using the Facebook C# SDK hence FacebookApp.Get
EDITED
I have been watching some pluralsight videos on the TPL library and went with the pattern in the picture below. As you said there is the main thread coming in from the Create Controller itself, but I still needed to spawn 4 separate network tasks to do the network calls in parallel. I fix the HttpContext error by not having the function that was being called in 4th task to not rely on HttpContext at all.
The net result for me now is a more highly performance method call as promised with parallel programming.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您调用 Web 服务，并且不想阻止请求线程，最好使用 异步页面（Web 表单）或异步控制器 (MVC)。如果您启动一个任务并需要从任务返回的值，您仍将等待该操作完成，这仍然会阻塞请求线程。
请注意，由于 ASP.NET 默认情况下是多线程的，因此您不应在单个 Web 请求中启动多个线程。
更新：
请参阅此有关网络应用程序中多线程的答案了解更多信息。
If you call to a web service, and don't want to block the request thread, it's better to go with asynchronous pages (Web Forms) or asynchronous controllers (MVC). If you spin up a
Taskand need the value returned from the task, you will still be waiting for that operation to complete, which still blocks the request thread.Note that since ASP.NET is multi-threaded by default, you shouldn't spin up multiple threads within a single web request.
UPDATE:
See this SO answer about multi-threading in web applications for more info.
上面屏幕截图中的实现将导致在等待网络调用完成时浪费 CPU 资源，特别是 ASP.NET 也使用的线程池线程。如果您想最大化吞吐量，您必须使用不会导致CPU线程阻塞的异步I/O调用。为了充分受益，那么您还需要使用@Steven提到的异步控制器。
然而，关于不应在 ASP.NET 请求实现中使用多个线程的建议并不是真正的好建议，因为它并不是那么黑白分明。确实，ASP.NET 请求本身显然是在多个线程上执行的，因此从顶部已经有很好的并行性，但是如果您要调用涉及 I/O 的其他层，您需要放弃 ASP在这些 I/O 操作发生时使用 .NET 线程，以便 ASP.NET 可以在这些 I/O 操作挂起时处理更多请求。
与往常一样，这取决于实现的具体情况，但在您的情况下，由于您正在调用 Facebook 之类的东西，我可以告诉您，在这些调用上使用异步绝对会带来好处。
The implementation you have in the screenshot above is going to result in wasting CPU resources, specifically thread pool threads which ASP.NET also uses, while waiting for network calls to complete. If you want to maximize your throughput you must use asynchronous I/O calls that don't result in blocking a CPU thread. In order to fully benefit from that then you would also need to use async controllers as @Steven mentioned.
However, the advice that you shouldn't utilize multiple threads in an ASP.NET request implementation is not really good advice because it's not as black and white as that. It's true that the ASP.NET requests themselves are obviously executing on multiple threads and so there's already a good degree of parallelism from the top, but if you're making calls out to other layers that involve I/O you want to relinquish the ASP.NET thread while those I/O operations are occurring so that ASP.NET can process more requests while those I/O operations are pending.
As always, it depends on the specifics of an implementation, but in your case since you're calling out to something like Facebook I can tell you you will absolutely see benefits by using async on those calls.