我想听听一些关于并行计算方法（包括并行扩展（例如 June CTP）的潜在用途）在 Web 应用程序中的作用（如果有的话）的意见。这种方法适合和/或不适合什么场景？
我对 IIS 和 Web 浏览器线程任务的确切理解是相当有限的。如果有人对此有很好的理解，我将不胜感激。我更想知道 IIS 和 Web 浏览器的工作方式是否限制了在 Web 应用程序中创建线程和/或异步任务的投资回报率。
提前致谢。
Greg
问问题
1050 次
5 回答
3
好吧，Web 服务器提出了一个有趣的挑战，因为它们已经是高度线程化的，为并行请求提供服务。因此，在繁忙的站点上，您不能依靠窃取大量内核来达到目的。当然，如果您只期望流量较少，并且您的网站需要大量处理（数据处理等），那么您可能会节省一些费用。
我希望 Parallel Extensions 在客户端或专用服务应用程序中工作得更好，您可以合理地期望内核可供您 [ab] 使用。
于 2008-12-18T14:40:43.823 回答
0
在显示逻辑的情况下，使用 PE 可能不会有很多好处，因为这些功能对于应用程序来说通常是快速而直接的处理。留给微软在 IIS 中开发并行架构。
但是，如果您可能有长时间运行的报告或业务逻辑需要花费大量时间来执行，那么您会注意到好处。在这些情况下，使用 PE 可以显着加快应用程序的速度，并结合缓存为最终用户提供更强大的用户体验。
一个例子是我们运行复杂的报告，这些报告会遍历大量数据并需要对其进行解析或对其执行某种功能。使用 PE 可能需要 20 分钟，而在 Web 应用程序中运行业务逻辑则需要几分钟。（忽略数据库，因为数据库可能已经线程化）。我们有一个预订功能，告诉我们从供应商那里购买什么，并且在穿线后从 5 小时到 30 分钟，因此穿线/PE 有实实在在的好处。
第二种情况是您可能需要为每个客户解析复杂的数据。虽然应用程序请求可能在不同的线程上执行，但可能还有其他空闲线程可以利用并利用它们的功能。为此目的使用 PE 是有意义的。
于 2009-01-06T22:39:07.483 回答
0
您可以使用 TPL 通过迁移到异步模型来改进 I/O 绑定操作。您还可以通过在低负载情况下更多地利用 Web 服务器上可用的未使用处理器容量来改善请求延迟。您需要仔细考虑这一点，因为在处理器已经 100% 使用的高负载下，增加更多并行性会降低服务器的吞吐量。
这在 Parallel Extensions 团队博客上进行了讨论：
于 2010-05-07T15:36:07.267 回答
0
我不会过多关注基于 Web 的应用程序中的并行扩展。如果您在一个页面中确实有多个远程请求（数据库调用或远程 Web 服务），则可能值得研究。
基于 Web 的应用程序已经是高度并行的。而且您不会从服务器端方法中的并行执行中获得太多收益。一个例外是关于服务器端代码中的多个远程请求（dbms 或 web 服务），您的大部分时间都花在等待远程资源上，也可能让您在多个请求上的等待时间并行运行而不是序列化请求。
例如，我有一个门户页面，我计划在单独的线程中进行所有数据库调用和 web 服务调用，并将结果推送到 httpcontext 的项目集合中，以便在页面生命周期的后期在用户控件中使用。不过，在这里也可以选择使用 ajax 技术。
于 2008-12-19T06:24:02.283 回答
-3
您简陋的 Web 服务器通常最适合提供可以缓存的静态内容。我真的怀疑它是否适合并行处理（除了出于兴趣的纯实验）。
评论后有些清晰：我的原意不是 IIS 不并行处理。我的观点是，“并行处理”实际上不仅仅是为 Web 应用程序提供服务。我对并行处理问题的理解是一个大的计算问题，它被分解成更小的部分，然后在多个处理器上并行执行。
对于此类问题，在同一处理器上执行多个线程实际上比运行单线程效率低。IIS 可以混入并行处理吗？你打赌。它是理想的平台吗？不。
于 2008-12-18T14:45:00.227 回答