IBM Websphere MQ Latency用于存储持久消息.NET客户端

Question

When MQ server receives Put() request, what factors are affecting when messages are stored? Below is potential factors:

1) caching messages in memory for some times, or

2) when certain number of messages are received

3) When certain byte threshold of messages are received

4) MQ server save it IMMEDIATELY for each message.

UPDATE

That is, when Put() returns, has messages been saved to hard disk, or in cache depending on factors above?

Any information and links to official doc would be great appreciated.

Below is a simple scenario where Put() is used.

     void PutMessages()
    {
         Open(ConnectionMode.Write);

            // putting messages continuously
            for (int i = 1; i <= numberOfMsgs; i++)
            {
                PutMessage(GetMessageInBytes(i));
            }

            queue.Close();
            queueManager.Disconnect();          
    }

    void PutMessage(byte[] messageString)
    {

        // creating a message object
        message = new MQMessage();
        message.Write(messageString);
        message.Format = MQC.MQFMT_STRING;
        message.CharacterSet = 1208;// IbmUtf8Encoding;
        message.Persistence = MQC.MQPER_PERSISTENT;

        var options = new MQPutMessageOptions
        {
            Options = false ? MQC.MQPMO_SYNCPOINT : MQC.MQPMO_NO_SYNCPOINT
        };

        queue.Put(message, options);            

    }

    public void Open(ConnectionMode connectionMode)
    {
        var connectionSettings = new Hashtable
        {
            {MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED },
            {MQC.CONNECT_OPTIONS_PROPERTY, MQC.MQCNO_RECONNECT }
        };

        int openOptions = 0;

        switch (connectionMode)
        {
            case ConnectionMode.Read:
                openOptions = MQC.MQOO_INPUT_SHARED + MQC.MQOO_FAIL_IF_QUIESCING;
                break;
            case ConnectionMode.Write:
                openOptions = MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING;
                break;
        }
        queueManager = new MQQueueManager(queueManagerName);
        queue = queueManager.AccessQueue(queueName, openOptions);
    }


    public enum ConnectionMode
    {
        Read,
        Write
    }

Answer 1

In the IBM MQ v9 Knowledge center page " Application design and performance considerations " it has this two say:

Put persistent messages under syncpoint

Persistent messages should be put and got under syncpoint. This is because when getting a persistent message outside of syncpoint, if the get fails, there is no way for the application to know whether the message has been got from the queue or not, and whether, if the message has been got, then it has also been lost. When getting persistent messages under syncpoint, if anything fails, the transaction is rolled back and the persistent message is not lost because it is still on the queue. Similarly, when putting persistent messages, put them under syncpoint. Another reason for putting and getting persistent messages under syncpoint is that the persistent message code in IBM MQ is heavily optimized for syncpoint. So putting and getting persistent messages under syncpoint is faster than putting and getting persistent messages outside of syncpoint.

However, it is faster to put and get non-persistent messages outside of syncpoint because the nonpersistent code in IBM MQ is optimized for being outside of syncpoint. Putting and getting persistent messages go at disk speeds because the persistent message is persisted to disk. However, putting and getting non-persistent messages go at CPU speeds because there is no disk write involved, not even when using syncpoint.

If an application is getting messages and does not know in advance whether they are persistent or not, the GMO option MQGMO_SYNCPOINT_IF_PERSISTENT can be used.

---

Chris Frank from IBM gave a presentation at Capitalware's MQ Technical Conference v2.0.1.6 titled More Mysteries of the IBM MQ Distributed Logger , Slide "What if I Don't Use Transactions? (2)" on Page 87 states:

• Contrast this with not using Syncpoint:
  • Each MQPut will result in at least one physical write to the log file
    • The putting application will be blocked during this time