Thanks for the clues.
We do capture the message ID after we put them on the queue but if you mean do I include the wait for a response from the 3rd party app (which comes on a different "OUT" queue) then no I am only measuring the time for the MQDestination.Put method to complete.
I shall try turning off persistence next and see what that does.
Original Message:
Sent: Tue May 10, 2022 06:28 AM
From: Colin Paice
Subject: Am I right in thinking 15 minutes to put 5,000 messages to a queue is very slow?
As Morag says I would expect it to be in seconds, not in minutes in a well set up environment, where the application is close to the server.
I presume you are using a client connection, and you are measuring the duration the mqput takes, not the duration of a "MQPUT and wait for a response message"
Some questions which may help pin it down
1 Are you using persistent or non persistent messages? non persistent have no logging
2 Are you using in syncpoint or out of syncpoint - see below
3 What size are your messages. Big messages take longer than small messages - anything under 10KB is small. Anything over 100KB gets to be large.
4 If your client is distant from your server, you may get network delays (especially if your messages are large). How long does a ping take? under 10 ms is good.
If you want to "play" to see the impact
1 make the messages non persistent
2 use a small message (100 byte) and measure the time for the put.
Syncpoint
There are two modes of putting messages
Put in syncpoint, put in syncpoint,put in syncpoint, commit ( which writes to the log, and the messages are visible)
Put out of syncpoint (which does put, commit under the covers) Put out of syncpoint (which does put, commit under the covers)... (no commit, if there is a commit, it has nothing to do)
so
1 puts in syncpoint should be fast, and the commit - will be slower because of the log write.
2 put out of syncpoint will be slower than put in syncpont , because they have to do log I/O.
If you are doing database updates as well, I hope your requests are in syncpoint, so your commit does both database and MQ .
Colin
------------------------------
Colin Paice
Original Message:
Sent: Tue May 10, 2022 06:10 AM
From: Morag Hughson
Subject: Am I right in thinking 15 minutes to put 5,000 messages to a queue is very slow?
You are correct in thinking that 5000 messages in 15 minutes is slow. My little laptop here can put 5000 persistent messages (10000 bytes in size) in around 17 seconds - that's seconds not minutes.
What version of MQ are you using? I assume an old-ish one as you are still using the WebSphere brand to refer to it. There's no point in us advising you things to try if they are not available on your version of MQ.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Tue May 10, 2022 05:51 AM
From: Philip Bathe
Subject: Am I right in thinking 15 minutes to put 5,000 messages to a queue is very slow?
I am in a very small development team that has no experience of Websphere and we have inherited a legacy system that communicates with a third party system via Websphere queues.
Most of the time everything ticks along happily, however we are beginning to get times when traffic increases to nearly 5,000 messages in the space of a few seconds and our poor old system is taking almost 15 minutes to put them onto a queue.
I don't expect anyone to tell what is wrong from this basic description, I am simply wondering if I am right in thinking putting 5,000 messages to a queue could or even should take a lot less time? Like maybe a few seconds to a minute tops sort of thing.
More details for those that are interested:
By adding a load of logging to a version we put on a test server we were able to rule out the other activities of the code base (such as writing to databases and so on). We were seeing about 150 milliseconds per "put" command.
Our Websphere queues are hosted on servers in Brazil with our system hosted with AWS in East US but the administrators in Brazil assure us that this difference in location is not an issue.
The C# code sends the messages in batches of 200 by starting a transaction on the queue, looping through each message and putting them to the queue, updating a database for all 200 messages and then committing the transaction (the DB update is pretty much instant).
This being legacy code the initial temptation is to assume they have done something horrifically wrong but, being a websphere newbie myself, it is going to be tricky for me to spot it!
------------------------------
Philip Bathe
------------------------------