【问题标题】:What is the best way scale out work to multiple machines?将工作扩展到多台机器的最佳方法是什么?
【发布时间】:2010-10-07 22:18:50
【问题描述】:

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

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

【问题讨论】:

  • 试试 ActiveMQ 而不是 MSMQ,喜欢它。
  • 取决于应用程序,如果您已经在使用 SQL Server,那么 SQL Server Service Broker 而不是 MSMQ 可能会是一个主要的胜利。

标签: c# performance scaling


【解决方案1】:

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

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

【讨论】:

    【解决方案2】:

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

    然后他将整个基础设施推到了 Amazon 的 EC2 上。

    Here's his slides from the presentation - 他们应该给你基本的想法:

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

    【讨论】:

      【解决方案3】:

      您可能需要考虑 Rhino Service Bus 而不是 MSMQ。来源here

      【讨论】:

      • Rhino Service Bus 不是建立在 MSMQ 之上的吗?
      • 是的。我的意思是将其作为 MSMQ 的包装器。
      【解决方案4】:

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

      请务必查看您的client-side connection limits。默认情况下,我认为系统默认是2个连接。我自己没有尝试过,但是通过使用此属性增加连接数,理论上您应该看到通过从单台机器生成更多连接来生成更多请求方面的乘数效应。微软论坛上有more info

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

      你有一个很好的起点。将其投入运行,然后继续关注性能和吞吐量。

      【讨论】:

      • 希望我可以标记所有答案 - 都非常有帮助,但是这个让我在我的 app.config 中设置了 maxConnections,这导致速度提高了 2 倍。仍然不是我们想要的,所以我们正在研究 MSMQ、Rhino 和 EC2/Azure。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-10-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多