| Author |
Message
|
| MartynB |
 Posted: Mon Jan 14, 2008 3:19 am Post subject: Use of MQCMIT? Expert required... |
 |
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
Hi,
For a project I'm working on I've written a stress test tool which uses MQClient to send many requests to multiple queues, read the responses and calculate min/max/average response times.
To keep this timing as accurate as possible I use the delta between the PutDate/PutTime for the request and the PutDate/PutTime of the response. I defer performing reads until all the puts are complete.
This all works fine so far.
To make this more accurate I also want to get this to work under syncpoint to commit a large amount of data so that it is all available to the destination queue manager/application(s) at once. I believe this will give as accurate timings as possible (upto a limit of 10000 msgs given that I'm using MQClient) however I have a problem...
If I use syncpoint then the PutDate and PutTime I have been using to calculate the timings will be inaccurate because this will not be the time that all the messages are available to the queue manager. What I want to do is get the PutDate and PutTime from when I call MQCMIT but I don't think this is possible. The only way I can think of achieving this is to use the PutDate and PutTime of the LAST request for ALL the messages I put to the queue then immediately call MQCMIT however this won't be 100% accurate. Does anyone have any ideas how I might acheive this?
Any help appreciated.
Regards,
Martyn |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jan 14, 2008 3:30 am Post subject: Re: Use of MQCMIT? Expert required... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MartynB wrote: |
| however this won't be 100% accurate. |
How accurate does it need to be? Seriously, what is the granulatity of the timings and what is the permissible error?
Where I'm heading here is that most stress testing performs 2 principles tasks: to prove the system doesn't colapse under stress; to prove that the response time doesn't increase past SLA under stress. If your application has an non-load response time of 10 seconds then you're measuring to the nearest second. If instead it's 100 ms then you've got a problem.
Also bear in mind that stress tests are always approximations of how the system performs because you're not using live data in a live environment. This again touches back on my question "how accurate does it need to be".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MartynB |
| Posted: Mon Jan 14, 2008 3:36 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| Thanks for your reply, I guess I'm just trying to keep it as accurate as possible so I'm canvassing opinion as to whether there is a more accurate or better way of achieving these results. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 14, 2008 3:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And keep in mind that if your boxes are not ntp time synchronized your values will have little meaning if you cannot take into account the time difference between the boxes: i.e. the reply can be timestamped from before the request...
And if you have different boxes in production you will NEED to test with multiple boxes just because of network latency and such...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| MartynB |
| Posted: Mon Jan 14, 2008 3:45 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
I'm a little confused by this comment...
I thought that the destination queue manager was responsible for generating the PutDate/PutTime, is this not the case?
I use the <i>difference</i> between these values. Is there a better way of doing this? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 14, 2008 3:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| MartynB wrote: |
I'm a little confused by this comment...
I thought that the destination queue manager was responsible for generating the PutDate/PutTime, is this not the case?
I use the <i>difference</i> between these values. Is there a better way of doing this? |
There is no better way unless you want to take the time between the put of the request and the receive of the reply... but this does not measure in any way the performance of the MQ system. It measures the MQ system, the server APP performance and the network performance...+ any resource performance (DB) involved in the server app...
Imagine there is a time diff of 10 seconds between your machines.
Imagine the round trip takes one second and single trip 500 ms.
So if you go by diff received time - put time you will have either -9500 ms or 10500 ms... This is why it is so important to have the machines time synched!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 14, 2008 4:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MartynB wrote: |
I thought that the destination queue manager was responsible for generating the PutDate/PutTime, is this not the case?
|
No, it's the time it was PUT to the source queue manager which sets up the MQMD.
The only other option you have is to use COA messages to time when the message actually arrives at the destination queue manager; their Put Time is the time they were generated by the arrival of the message. Two immediate problems with these:
the timing issue fjb_saper correctly points out - the time is generated by reference to the local clock so unless all the machines are time syncronised the results will be distorted;
the production of these messages in a stress test situation will impact queue manager performance and distort the figures again.
I again repeat my question of how accurate does it need to be? As opposed to how accurate it should ideally be?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MartynB |
| Posted: Mon Jan 14, 2008 5:39 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| Vitor wrote: |
No, it's the time it was PUT to the source queue manager which sets up the MQMD.
|
Sorry, perhaps I've been a little ambiguous - this is what I meant by destination queue manager (i.e. the queue manager the MQClient bindings connect to, not a remote queue manager). So the PutDate and PutTime are generated by the queue manager (local clock on the target server) and for my test I am only using one queue manager (I didn't mention this before) therefore the delta between the request and reply PutDate/PutTime should be accurate.
| Vitor wrote: |
| the production of these messages in a stress test situation will impact queue manager performance and distort the figures again. |
This is why I want to put these messages under syncpoint then commit them all at once.
Thanks for your quick replies guys, great forum  .
I've writing MQ tools/utilities on and off for 5 years or so and I've never really used this forum before but I will do now.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 14, 2008 5:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MartynB wrote: |
| Vitor wrote: |
| the production of these messages in a stress test situation will impact queue manager performance and distort the figures again. |
This is why I want to put these messages under syncpoint then commit them all at once. |
But once the commit goes through the destination queue manager will start generating COA messages while simultaniously servicing the GET requests from the reading application. That's what I meant about distorting performance.
| MartynB wrote: |
Thanks for your quick replies guys, great forum .
|
We aim to please. Thank you for your well worded and descripitive post; a pleasant change from the more "I am put msg but it not. Pls give detailed instructions" we sometimes get!
| MartynB wrote: |
I've writing MQ tools/utilities on and off for 5 years or so and I've never really used this forum before but I will do now. |
You'll be most welcome. Please don't be shy about sharing any experience. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MartynB |
| Posted: Mon Jan 14, 2008 6:58 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| Vitor wrote: |
But once the commit goes through the destination queue manager will start generating COA messages while simultaniously servicing the GET requests from the reading application. That's what I meant about distorting performance.
|
Don't COA's only get generated if the relevant report options are set? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 14, 2008 7:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MartynB wrote: |
| Vitor wrote: |
But once the commit goes through the destination queue manager will start generating COA messages while simultaniously servicing the GET requests from the reading application. That's what I meant about distorting performance.
|
Don't COA's only get generated if the relevant report options are set? |
Absolutely yes. My entire post was based on the assumption you'd taken my sugestion further up the thread to deal with a remote queue manager (which someday presumably you'll need to - very few production solutions involve a single box)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 14, 2008 7:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, remember that committing larger transactions can have a larger impact on logs than committing more but smaller transactions.
And likewise have a larger effect on over all system performance - for example by causing channels to wait for free log space or roll back transactions due to unavailable free space.
So you may also be distorting the performance measurements by doing everything in one big commit.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MartynB |
| Posted: Mon Jan 14, 2008 8:45 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| Vitor wrote: |
My entire post was based on the assumption you'd taken my sugestion further up the thread to deal with a remote queue manager (which someday presumably you'll need to - very few production solutions involve a single box) |
Cool. I appreciate that running across multiple queue managers will scew results somewhat. However, for my purposes, I'm only using a single queue manager. I've written it as MQClient for flexibility but I intend to run it on the same queue manager to eliminate network (or get the MQCMIT approach I've described above working!).
In particular my task is to tune a high throughput application such that I can prioritise the rate at which certain traffic is handled. I.e. I have 3 types of feed each of which need to process x number of messages per second at peak load.
Without a tool that accurately monitors response times and gives msgs/second statistics this would prove difficult. |
|
| Back to top |
|
|
| MartynB |
| Posted: Mon Jan 14, 2008 8:47 am Post subject: |
|
|
Novice
Joined: 14 Jan 2008
Posts: 24
|
| jefflowrey wrote: |
Also, remember that committing larger transactions can have a larger impact on logs than committing more but smaller transactions.
And likewise have a larger effect on over all system performance - for example by causing channels to wait for free log space or roll back transactions due to unavailable free space.
So you may also be distorting the performance measurements by doing everything in one big commit. |
The messages are v small (less than a few 100 bytes) and the smallest UOW I can use for accurate results is 502 messages however I will probably use 5020. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 14, 2008 8:49 am Post subject: Re: Use of MQCMIT? Expert required... |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MartynB wrote: |
The only way I can think of achieving this is to use the PutDate and PutTime of the LAST request for ALL the messages I put to the queue then immediately call MQCMIT however this won't be 100% accurate. Does anyone have any ideas how I might acheive this?
|
If your logic is:
1. MQCONN
2. MQOPEN
3. MQPUT
. MQPUT
. MQPUT
102. MQPUT
103. MQCMIT
104. MQPUT
. MQPUT
. MQPUT
202. MQPUT
203. MQCMIT
204. MQCLOSE
205. MQDISC
If you don't do anything between the last MQPUT of the batch and the MQCMIT, I would be surpised if you lost more than a few milliseconds, assuming the network connection is good between the MQClient machine and the MQ server. Notice I used batches of 100, for reasons Jeff outlined.
If you want, you could grab the timestamp from the O/S of your MQ Client machine before and after the MQCMIT, see how long that took, and then add that to the last MQPUT's time. But now you're really splitting hairs. If you'll never be 100% accurate, does it make a diff if you are 99.99 or 99.999% accurate? 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
