| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Mainframe MIPS Breakdown |
« View previous topic :: View next topic » |
| Author |
Message
|
| queuetip |
 Posted: Mon Jun 06, 2005 12:18 pm Post subject: Mainframe MIPS Breakdown |
 |
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
Obviously, how the queues are allocated (pagesets and bufferpools and logsize and MAXUMSG) plays a significant role of performance tuning. We believe we have verified and tuned the administration pieces though. The throughput is pretty good, everything is going to "write cache memory"...the problem now is just MIPS!
Obviously how the application is coded and the commit/backout size of persistent messages also plays a significant role. We looked at the app for low hanging fruit and the code looks pretty responsible. We've got concurrent processing going on as well. To go any further, we need to know more about the MIPS going on within MQSeries behind the scenes.
When you issue a GET and do a wait (WAITINTERVAL) in z/OS, how is that really implemented? Is it like NT and UNIX where it acts like a callback function...or does it poll over and over and over?
I was wondering if the grand masters out there (or IBM) had a breakdown of MIPS used by MQSeries task - connect, open, get options, gets, put options, puts, persistent logging, the lock handling tasks, etc.?
Any help is much appreciated.
Thanks! Mike |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Mon Jun 06, 2005 12:41 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
When you issue a GET and do a wait (WAITINTERVAL) in z/OS, how is that really implemented? Is it like NT and UNIX where it acts like a callback function...or does it poll over and over and over?
|
I believe it waits for an ECB to be posted.
Not sure I can answer the MIPS used by various 'features' but our queue managers are not 'big hitters' in terms of CPU. You have tuned Address spaces but are you sure you have them in the right WLM enclave? |
|
| Back to top |
|
|
| queuetip |
| Posted: Mon Jun 06, 2005 3:28 pm Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
Is there much tuning opportunity within WLM for handling the transaction that would impact MQSeries MIPS? If so, could you provide some examples? (i.e. I'm not too familiar with WLM)
I will provide a little more detail...
CICS txn (ABCD) starts the unit of work. It puts a message on a non-persistent queue that is being monitored via another CICS txn (EFGH) that acts as a daemon and has issued a GET WAIT INTERVAL to pull in the request message. ABCD txns can run in parallel. Each ABCD waits for a reply message from the EFGH using the MSGID/CORRELID model.
The EFGH daemon transaction maintains a socket connection to another system to retireve data (no MQSeries)...however, once the data returns from the socket EFGH puts a reply message on a reply queue for the ABCD transaction. When ABCD gets the reply, it issues a COMMIT at that time. ABCD will timeout if no data is returned under a minute.
The user noticed an especially large spike in MQSeries MIPS when the socket connection is DOWN. This is why I was wondering about the MIPS when in GET INTERVAL mode. See any other opportunities here?
Thanks!
Mike |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Jun 07, 2005 5:11 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The WLM service class is probably the most important...and remember the CHIN as well as the MSTR address space
Based on your description of the problem I would tend to be looking more at the TCPIP address space.
As for the spike, again, based on your description I would check the application. What does it do if the Put of the request message fails? Does it keep on trying? |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 07, 2005 10:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
MQI calls like MQCONN and MQOPEN consume more resources due to security checking etc than MQGET/PUTs or MQCLOSE or MQDISC.
So keep connections and queues open for multiple operations whenever possible.
The MQGET WAIT will result in either a CICS wait or a MVS wait with a ECB being posted when it's time to resume processing, MIPS are not being wasted during this time. Much better to let the QM wait on the ECB than it is to repeatedly issue MQGETs. |
|
| Back to top |
|
|
| queuetip |
| Posted: Tue Jun 07, 2005 12:58 pm Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
| Quote: |
| The WLM service class is probably the most important |
Hmmm. How does this generate extra MQSeries MIPS? Could MQSeries swap storage out? Is it because the call to the other txn is within the syncpoint? Thanks.
| Quote: |
| ...and remember the CHIN as well as the MSTR address space |
I may not have been clear - but the CHIN is not affected. The queues are all local on the mainframe. The TCPIP connection between the daemon transaction and the web application does not use MQSeries. Only after results come back does the daemon format a reply message for the first message. If this is what you understood, please help me understand how CHIN comes into play. Thanks.
| Quote: |
| Based on your description of the problem I would tend to be looking more at the TCPIP address space. |
Since the TCPIP address space in question here is a socket connection and not MQSeries (although within the original MQSeries commit)...so how would that generate MQSeries MIPS? Thanks.
| Quote: |
| As for the spike, again, based on your description I would check the application. What does it do if the Put of the request message fails? Does it keep on trying? |
This is an excellent question! I will pursue this with the application programmer. Thanks - I look forward to hearing more about the details above. |
|
| 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
|
|
|
|
