| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to measure the duration of the message in MQSeries |
« View previous topic :: View next topic » |
| Author |
Message
|
| Fannyfcwong |
 Posted: Tue Aug 06, 2002 8:14 am Post subject: How to measure the duration of the message in MQSeries |
 |
|
Novice
Joined: 04 Jul 2002
Posts: 13
|
I have a 3 tier structure application using MQSeries between each tier. Each tier are using different platform, say, frontend is a AIX, middleware is OS/390 and backend is HP-UNIX.
Each application in their own platform has a logging of the message get time and write time. They all claim that their response time is very fast. They blame for the MQSeries for holding the message and affect the overall performance. As the clock within these 3 platforms are different, the MQSeries Put time cannot be used to measure the time gap.
Would anyone know that how I can accurately measure the response time of the message and prove that the time for MQSeries to handle the message is very short? |
|
| Back to top |
|
 |
| bduncan |
| Posted: Tue Aug 06, 2002 9:45 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I actually did extensive performance testing on a 3-tier architecture a while back. It was Linux on the front end, Linux in the middle, and AIX on the backend.
You are correct, if the clocks on each of the machines aren't in perfect sync, you can't reliably compare put times. However, you can setup roundtrip tests.
Since you are just trying to prove to your misinformed co-workers that the bottleneck doesn't lie within MQSeries, then you can bypass their applications completely for these tests. The test consists of the following. On a frontend queue manager, have a bare bones program put a message to a on the middle tier. The content of this message will simply be a timestamp of when the message was created. Now, using several copies of another program that simply does a get followed by a put, you can propogate the message through the 3 tiers, down to the backend, and back to the frontend. It will land on a reply queue that the original putting application is now watching, and it will get based on CorrelId. Now you take the current time, and compare it to the timestamp in the message. Since you are looking at the message on the original queue manager, there is no issue of clock syncronization.
I've run literally millions of messages through tests such as these to test the throughput of a three tier system, varying factors such as persistence, syncpoint, message size, etc...
I might be able to dig up some of the excel spreadsheets with my results, or even the C programs I used to run the tests...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 06, 2002 10:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Make sure you factor in the network in the above scenario. A slow network may make it seem like MQ is slow, but it can handle messages only as fast as they are delivered.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Fannyfcwong |
| Posted: Tue Aug 06, 2002 8:10 pm Post subject: |
|
|
Novice
Joined: 04 Jul 2002
Posts: 13
|
Hi bduncan and PeterPotkay,
I have already performed a throughput test before the application was launched. However, each time when the performance is degraded, they all could provide the statistics to show that their response time was as usual, say within 1 to 2 seconds. Even the teams who take care of the CPU and Network claimed that everything was normal.
I really need some evidence to prove that bottleneck at that moment is not on MQSeries.
Do you think it s possible to write a security exit program,for example, to get the time difference between two platforms and place it in somewhere (I don't know where is feasible)? The application team can calculate the different between actual message input time and the time they get the message.
Do you have any idea? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Aug 06, 2002 9:12 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
I would use a message exit and hook it to each of the application's queues plus the XMITQ (transmit queue) between each queue manager.
Log as much of the info as you can. e.g. All of the MQMD (or at least most of it - date, time, ApplId, MsgId, CorrelId, etc..) plus a good portion of the user data (try to get at least 50% of it).
later
Roger... |
|
| Back to top |
|
|
| Fannyfcwong |
| Posted: Wed Aug 07, 2002 4:00 am Post subject: |
|
|
Novice
Joined: 04 Jul 2002
Posts: 13
|
Hi Roger,
Thanks for you opinion.
However, the time out-sync problem between the platforms are still exist even I have logged the MQMD. I would like to know the exact time delay when frontend application put the message and another application get the message.
Do anyone have any idea?
 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 07, 2002 4:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Well, here is an idea that may or may not be feasible.
Put the message with a known Expiry value, like 1000. Since Expiry is only decremented while a message is on a local queue (including XMIT), at the end of the trip, the amount of time removed from Expiry shows how much time the message was on the queues. Don't know if this proves anything in of itself (i.e. if the app never does its GET, the Expiry will go down to zero, but you cant blame MQ for being slow here), but it may be valuable if the app has an oustanding GET on the queue so that it grabs the message as soon as it can.
Also, add code to display the local system time before and after each MQ API call. This can tell you that the MQCONN took xxx millisecs, the MQOPEN took, xxx ms, the MQPUT took, etc.
This is a pain to code all this, but I think would give real good results as far as how ong MQ is taking. It would probably be tedious to compile all the data as well.
Here is my queustion: Isn't there a tool on the market that does this for us automatically with minimal overhead to the process its monitoring while compiling the data in a meanigful way? I got a transaction that originates on the MainFrame, goes to MQSI for data transformation, is put to a NT box for the actual work, and then the reverse is taken for the reply. How can I tell my customer that this what the MF MQ interface encompassed, how long did the MQSI take, etc. What if I toggle persistence on and off at the source: how much does it affect everything along the way? There's gott abe something that does this, no?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Aug 07, 2002 8:22 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
That was a simple solution. Since you would have the put & get times for XMITQ, (each hop through the queue managers) and the final local queue(s), you could move all of the message exit logs to a single box and then run some jobs to do pattern matching on MsgId and / or CorrelId.
But of course it would be guess-estimate because of the time clock differences.
If you have the time (no pun implied  ), you could built the message exit to do a ntp request via UDP to an atomic clock (RFC867). Therefore, each get & put would invoke the message exit and correctly log the the "real" date and time plus MQMD & data to a message exit log. Or if you have a firewall blocking port 13 to the outside world, you could setup your own "time" server running on a box (MVS, Unix or WinNT - it does not matter).
A few years ago, I played around with the sample code for the daytime client and server application from the book "Windows Sockets Network Programming". If I remember correctly, the code worked well for getting the correct time across platforms.
later
Roger... |
|
| Back to top |
|
|
| hkhan12 |
| Posted: Thu Aug 08, 2002 6:59 pm Post subject: Re: How to measure the duration of the message in MQSeries |
|
|
Voyager
Joined: 08 Aug 2002
Posts: 98
|
Hi MQ Experts,
I'm new in MQ area. I have setup MQ objects for passing msgs. from Oracle to Legacy(mainframe using OS/390)
NOTE: At Oracle side, using MQPACK library in order to interact with MQSeries, other than MQPACK, is there any other alternative?
This operation processing averagely 800 msgs a day with a msg. length of 3000 characters. But this 800 msgs can go upto 15,000 to 20,000 sometime.
I'm little nervous about its performance, if it reach to 15,000 to 20,000 msgs. a day.
If there are some performance related issues occured, what I should be doing with it?
Thanx, |
|
| Back to top |
|
|
| nimconsult |
| Posted: Thu Aug 08, 2002 9:58 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
20,000 x 3K messages on a day is far from being a performance challenge for MQ Series.
Locally it takes about 2 minutes to produce and consume 20000 x 3K persistent messages (116 seconds, test on P3-800 laptop, W2K, apps written in C, producer and consumer running in parallel, syncpoint every message on producer and consumer).
Remotely (more sensible to network configuration and traffic), it should take about 5 minutes.
My first impression is that performance issue should be considered on the other aspects of the application (complexity of processing and database access).
Other factorsif your app is clean: overloaded machines, overloaded network, overloaded disks, high pagination, old generation machines, old network-to-mainframe connection (old 3745 box designed for terminal emulation more than for EAI)...
Do you have specific performance concerns on MQ Series?
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| Fannyfcwong |
| Posted: Sun Aug 11, 2002 2:14 am Post subject: |
|
|
Novice
Joined: 04 Jul 2002
Posts: 13
|
Do anyone or IBM has a study on the comparison of MQ throughput, security and performance when using SNA or TCPIP, say, in mainframe platform?
If the performance is different, does MQ perform differently for different protocol or it is just related to the network? |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
