4

我们正在开发一个 .NET 应用程序,它必须对第 3 方 Web 服务进行多达数万次小型 Web 服务调用。我们更喜欢更“矮胖”的电话,但第 3 方不支持它。我们将客户端设计为使用可配置数量的工作线程,并通过测试获得了针对一台多核机器进行了相当优化的代码。但是,我们仍然希望提高速度,并且正在考虑将工作分散到多台机器上。我们精通典型的客户端/服务器/数据库应用程序,但对多台机器的设计却很陌生。因此,与此相关的几个问题:

  • 除了多线程之外,是否还有其他客户端优化可以提高 http 请求/响应的速度?(我应该注意这是一个非标准的 web 服务,所以是使用 WebClient 实现的,而不是 WCF 或 SOAP 客户端)
  • 我们目前的想法是使用 WCF 将工作块发布到 MSMQ,并在一台或多台机器上运行客户端以将工作从队列中拉出。我们有使用 WCF + MSMQ 的经验,但要确保我们不会错过更好的选择。今天还有其他更好的方法吗?
  • 我见过一些 3rd 方工具,例如 DigiPede 和 Microsoft 的 HPC 产品,但这些似乎有点矫枉过正。对这些产品有任何经验或我们应该考虑使用它们而不是我们自己的产品吗?
4

4 回答 4

3

听起来您的目标是尽可能快地执行所有这些 Web 服务调用,并将结果制成表格。鉴于此,您最大的效率控制将是通过扩展您可以发出的并发请求的数量。

请务必查看您的客户端连接限制。默认情况下,我认为系统默认是2个连接。我自己没有尝试过,但是通过使用此属性增加连接数,理论上您应该会看到通过从单台机器生成更多连接来生成更多请求方面的乘数效应。MS论坛上有更多信息

MSMQ 选项运行良好。我自己正在运行该配置。ActiveMQ 也是一个很好的解决方案,但是 MSMQ 已经在服务器上。

你有一个很好的起点。让它运行起来,然后转向性能和吞吐量。

于 2009-02-16T18:54:32.920 回答
1

在今年的 CodeMash 上,Wesley Faler 就这类问题做了一个有趣的演示。他的解决方案是将“工作”存储在数据库中,然后使用客户端下拉工作并在完成时标记状态。

然后,他将整个基础设施推到了亚马逊的 EC2 上。

这是他的演示文稿中的幻灯片——它们应该给你基本的想法:

我在本地使用多台 PC 做过类似的事情——管理工作负载的基础与 Faler 的方法相似。

于 2009-02-16T18:58:12.443 回答
1

如果您已优化代码,则可以考虑优化网络端以最小化发送的数据包数量:

  • 重用 HTTP 会话(即:通过保持连接打开将多个事务合并到一个会话中,减少 TCP 开销)
  • 将请求中的 HTTP 标头数量减少到最少以节省带宽
  • 如果服务器支持,请使用 gzip 压缩请求的正文(需要平衡 CPU 使用率进行压缩,以及节省的带宽)
于 2009-02-16T19:03:07.440 回答
0

您可能需要考虑Rhino Service Bus而不是 MSMQ。源代码可在此处获得。

于 2009-02-16T18:55:29.813 回答