每个请求与每个会话发出一个临时队列会影响性能吗？答案

【问题标题】：Will issuing a temporary queue per request vs per session affect performance?每个请求与每个会话发出一个临时队列会影响性能吗？
【发布时间】：2013-06-08 01:25:17
【问题描述】：

我一直在研究一些使用 JMS 与 ApolloMQ 消息代理接口的服务器端 Java。客户端通过执行以下操作向此服务器发出同步请求：

创建一个用于接收响应的临时队列
将请求发送到标准请求队列，“回复”指向新的临时队列
等待临时队列的响应
删除临时队列并重复

似乎为每个请求发布一个新的临时队列对于消息代理来说可能是昂贵的，并且可能会为每个请求引入额外的往返行程，以便首先创建临时目的地。我不想花很多时间亲自验证这一点，我有点希望知道的人能证实这种直觉。最好改为为每个客户端会话创建一个临时队列并使用消息/相关 ID 来匹配对请求的响应？

【问题讨论】：

标签： java performance jms activemq messaging

【解决方案1】：

从性能的角度来看：消息代理是否针对发送/接收消息或创建/删除队列进行了优化？

同样，数据库也没有针对动态创建和删除表进行优化；它是插入/更新/删除。

所以我会采用“相关 ID”的方式。

更新

这并不一定意味着将响应与请求放在同一个队列中。您可以为每个客户端/会话设置一个队列。

【讨论】：

感谢您的支持。跟我猜的差不多。

【解决方案2】：

使用相关 ID 涉及在消息队列上使用选择器 - 这比为请求响应的目的创建临时队列要慢（有关各种选项的比较，请参阅 http://camel.apache.org/jms.html 上的“通过 JMS 请求回复”）。

【讨论】：

所以你说为每个请求/响应周期创建一个队列比为每个客户端/会话使用一个带有选择器的专用队列更快？
我也想知道这个。如果所有客户端都在为他们的响应检查共享队列，那么我会更担心选择开销，但是每个客户端都有自己的专用临时队列不会减轻这种情况吗？
是的，这就是我的经验。据我了解，队列中的每个选择器都必须按顺序针对该队列中的每条消息进行评估。在这方面，它们与主题上的选择器不同，其中代理在决定将消息分发到哪些方之前评估每个选择器。如果您发送了 5 条消息，则最多有 5 个消息选择器需要一一评估。随着选择器数量的增加，性能会变差。
您能否提供有关“读取相关 ID 意味着使用选择器”的参考？无论如何，如果您一次从客户端/会话队列中读取每条消息，并使用相关 ID 在本地缓存中具有哈希键，则无需对队列进行顺序扫描。请描述什么可以更快。
抱歉，这就是我在字里行间读到的内容——这通常是它的完成方式，因为这意味着从队列中消费而不拉出消息。