远程 MSMQ 连接性能答案

【问题标题】：Remote MSMQ connection performance远程 MSMQ 连接性能
【发布时间】：2016-06-25 17:00:54
【问题描述】：

在跨远程私有 MSMQ 队列的迭代过程中，我们遇到了性能不足的问题。我们尝试使用两种 API 方法 - MessageQueue.GetAllMessages() 和 MessageQueue.GetEnumerator2() 并看到相同的结果。

似乎问题出在消息队列服务中，因为它始终只使用最多 15% 的 CPU（单核）。例如，如果我们遍历本地队列——我们使用 100% 的 CPU 并且可以在 2 秒内加载 100 万条消息，但对于远程队列，仅加载 10K 需要 30 秒！网络连接为 100MBPs。

有没有办法提高远程队列的 MSMQ 性能并强制它使用 100% 的 CPU 或网络？

【问题讨论】：

【解决方案1】：

MSMQ 已经过优化，可以尽可能快地运行 - 它不会因为激怒您而变慢。

远程队列的性能会很差。这不是使用 MSMQ 的最佳方式。通过“发送远程，读取本地”模型获得高性能。

远程访问使用 RPC，这在 LAN 上会很慢。如果您查看网络跟踪，您会看到所有来回通信。绑定到远程 RPC 服务并查询以查找 MSMQ 正在侦听的位置；绑定到远程 MSMQ RPC 侦听器；向侦听器请求消息；等等等等。

【讨论】：

我知道这不是一项典型的任务，在 99% 的情况下不需要快速远程查看。我们正在开发 MSMQ 查看器应用程序。我也明白“它不会因为激怒你而变慢”，我发布这个问题是为了确保没有办法让它像本地队列一样快。我很困惑为什么消息队列服务不使用所有可用的 PC 资源 - 如果 RPC 性能出现问题，那么为什么它不加载网络？或者可能只是使用 TCP 一条一条地发送消息并等待每条消息的接收确认。
也许有一些技巧或技巧如何配置请求，以便最小化 RPC 占用空间？
请求机器必须等待队列主机处理并响应 RPC 请求链。请求者还必须处理响应。网络在每个方向都增加了开销，所有这些都加起来了。我强烈建议您运行网络跟踪，以便您了解阅读一条消息需要多长时间。
"或者可能只是使用 TCP 一条一条地发送消息，并等待每条消息的接收确认。"不，您不是在发送使用 MSMQ 协议的消息。您正在通过 RPC 从远程队列中拉出一条消息。完全不同的机制。
"也许有一些技巧或技巧如何配置请求，从而最小化 RPC 占用空间？" MSMQ 制作请求。该应用程序只是说“给我东西”。提示 #1 - 不要从远程队列接收消息。提示＃2 - 不要搜索东西。如果有 1,000 条消息，而您依次查看每条消息以查找特定消息，那么您将死于老年。

【解决方案2】：

这可能与您的方案相关，也可能不相关，但它是提高 MSMQ 整体性能的一种方式。

如果您要发送包装一致类型的消息（例如，序列化类），则在发送之前缓冲它们并发送一条包含数组或项目集合的消息。

我正在处理一些序列化类并发送大量消息。我测试发现，如果我分批发送 50 个而不是单独发送，那么队列的大小会减少 75%。我没有花太多时间从那里优化。这取决于您的消息的大小。但这消除了发送单个消息所产生的大部分开销。

【讨论】：

此优化可能会破坏您使用队列的原因，因为意外失败会丢失尚未写入的缓存消息。
是的。我每隔几秒钟刷新一次缓冲区，无论它是否已满。但你是对的。队列中的消息比缓冲区中的消息更安全。由此产生的风险对于我的应用程序来说非常小，但对于另一个应用程序来说可能是不可接受的。就我而言，它是网站使用统计信息，因此如果应用程序突然停止以致无法刷新，那么我就有可能丢失数百万条消息。
感谢您的想法。不过，我们的问题是关于阅读消息以在网格中显示它们。

【解决方案3】：

尝试使用 TCP 连接语法并使用明确的数字 IP 地址 123.123.123.123。看看这是否会影响你的表现。如果确实如此，那么请考虑安全性。

您使用术语 GetMessage，但也谈论加载，所以我很困惑您是否想要消息接收“GetOne”或加载到队列操作的性能。

对于核心生产代码，我总是在消息上一次操作一个，因此我从不尝试 GetAllMessages 或 EnumerateAllMessages，除非在特定的管理功能中。

【讨论】：