Amqmdnet - open/close 每条消息的队列是否高效?

Amqmdnet - Is it performant to open/close the queue for each message?

我们有一些代码可以将消息发送到队列。它使用 amqmdnet dll 版本 8.0.0.6.

队列管理器(Queuemanager)在应用程序启动时实例化一次,并在整个过程中使用。发送消息时,会创建一个队列对象,然后将其关闭。我们应该为每条消息创建一个队列对象还是只使用一个实例更好?我们只写消息,不读。

这是一些代码:

 public QueueResult Enqueue(string message)
        {
            QueueResult result;
            using (var queue = _queueManager.AccessQueue(_queueName, MQC.MQOO_OUTPUT + MQC.MQOO_INPUT_SHARED + MQC.MQOO_FAIL_IF_QUIESCING))
            {
                var mqMessage = new MQMessage
                {
                    Format = "MQSTR",
                    Encoding = 546,
                    CharacterSet = 437
                };

                mqMessage.WriteString(message);

                var options = CreateOptions();

                queue.Put(mqMessage, options);

                result = new QueueResult
                {
                    CompletionCode = options.CompletionCode,
                    ReasonCode = options.ReasonCode
                };

                queue.Close();
            }

            return result;
        }

public IQueue AccessQueue(string queueName, int openOptions)
{
       return new Queue(mqQueueManager.AccessQueue(queueName, openOptions));
}

一篇较早的 IBM MQ developerWorks 文章有一些非常好的一般建议是“The top 15 WebSphere MQ best practices”。具体到你的问题,它说明如下:

Build with performance in mind

Although MQ was built for high transaction volumes, poor architecture and application design can compromise its ability to process messages as fast and effectively as possible. To mitigate potential performance issues, here are several recommendations:

  • Keep connections and queues open if you are going to reuse them instead of repeatedly opening and closing, connecting and disconnecting.

从 IBM MQ 客户端的角度来看,每个队列的打开和关闭都是网络上的一次往返,具体取决于 MQ 客户端和 MQ 队列管理器之间的延迟,这可能会导致 MQ 需要执行的处理之上的延迟当您打开和关闭队列时,例如检查您是否有权打开队列并打开磁盘上的底层 q 文件。


如果您将持久性消息放在工作单元之外,这可能会导致队列管理器与正在读取消息的应用程序发生锁定争用(如果您放入的队列,则读取应用程序可能是通道代理)是一个 QREMOTE)。

将多条消息放在同一个工作单元下也会提高性能,具体多少取决于底层存储。