| Author |
Message
|
| Maximus |
 Posted: Wed Feb 25, 2009 5:19 am Post subject: MQOPEN performance on Z/OS... |
 |
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
Hi,
We have WMQ 6.0 for z/OS installed with CAF for MQ Client connections. On the z/OS, with have a home built MQ CICS Adapter that calls the right service program to handle the requests.
We are doing a stress test using a Java application with 50 threads where
every threads get a MQ Connection and keeps it the whole thread life. Then each thread will do:
For 100 times {
MQOPEN(request queue)
MQPUT(request)
MQCLOSE(request queue)
MQOPEN(response queue)
MQGET(wait for response)
MQCLOSE(response queue)
Sleep(1 second)
}
We observe that at some point the MQOPEN can take up to 12 seconds in the worst cases on the request queue (which is rarely the case on the MQOPEN on the response queue) and the MQPUT can take up to 2-3 seconds in the worst cases. Where at the beginning of the test, all those calls would practically take only a few milliseconds.
Could CAF be the cause of the slow down because too many MQOpen are done on the Queues? Is there a way the configure CAF to handle more concurrent MQOpen calls?
Any idea where the problem could be?
Any help would be appreciated. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Wed Feb 25, 2009 6:06 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| IF you are opening and putting just one message why not use MQPUT1 it is much more effecient.....however even more efficient would be to move the OPEN and CLOSE for both queue to outside of your loop. That will definately increase performance. |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 6:21 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| kevinf2349 wrote: |
| IF you are opening and putting just one message why not use MQPUT1 it is much more effecient.....however even more efficient would be to move the OPEN and CLOSE for both queue to outside of your loop. That will definately increase performance. |
I just read about the MQPUT1 and in the Java API is:
MQQueueManager
public void put(String qName, String qmName, MQMessage msg,MQPutMessageOptions pmo, String altUserId) throws MQException;
Puts a single message onto a (possibly unopened) queue. If a send exit has been
specified, it processes the message before it is sent. See the description of MQPUT1
in WebSphere MQ Application Programming Reference for more information.
I will definitively try this out.
I want to keep the MQopen and MQclose because our WebApp is also doing the same thing since we have many request queues and therefore many response queue.
I will update this thread with my findings. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Feb 25, 2009 6:32 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
Maybe it is worth having a look at the adapters and dispatchers settings of the queuemanager CHIN address space..... (CHIADAPS and CHIDISPS)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 7:01 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| Mr Butcher wrote: |
| Maybe it is worth having a look at the adapters and dispatchers settings of the queuemanager CHIN address space..... (CHIADAPS and CHIDISPS) |
Good point!
Those values are currently set to:
CHIADAPS( 8 )
CHIDISPS( 5 )
MP16.pdf (Capacity Planning and Tuning for WebSphere MQ for z/OS) is suggesting:
CHIADAPS( 30 )
CHIDISPS( 20 )
what do you suggest? We have non-persistent messages that are under 100KB. |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 7:37 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| kevinf2349 wrote: |
| IF you are opening and putting just one message why not use MQPUT1 it is much more effecient.....however even more efficient would be to move the OPEN and CLOSE for both queue to outside of your loop. That will definately increase performance. |
Is there an equivalent JMS API call for MQPUT1? |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 25, 2009 7:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It is not ideal to keep doing MQOPENs as it has a higher system overhead (security checks etc).
On the request queue - there is no need to keeping closing the queue. Leave it open until the adapter closes down the connection.
On the reply queue leave it open unless the reply queue name is different from the last reply message sent (then close and open it).
You can use MQPUT1 but if the reply queue is often the same as the last reply queue then the above logic makes more sense. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 25, 2009 7:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you trying to stress test performance of CICS? Or the sending application?
Are you trying to optimize the performance of the sending application?
Are you trying to optimize for well-behaved applications? Or optimize with a mix of well-behaved and poorly behaved applications? |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 7:52 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| zpat wrote: |
It is not ideal to keep doing MQOPENs as it has a higher system overhead (security checks etc).
On the request queue - there is no need to keeping closing the queue. Leave it open until the adapter closes down the connection.
On the reply queue leave it open unless the reply queue name is different from the last reply message sent (then close and open it).
You can use MQPUT1 but if the reply queue is often the same as the last reply queue then the above logic makes more sense. |
The J2EE application we are trying to simulate takes the connection from a pool and therefore need to close the queues otherwise they will never be closed. This is why the java program we built to simulate the J2EE workload is doing the same calls.
MQPUT1 would be great to use, but I don't think its supported in JMS. Could someone confirm? |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 7:59 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| mqjeff wrote: |
Are you trying to stress test performance of CICS? Or the sending application?
Are you trying to optimize the performance of the sending application?
Are you trying to optimize for well-behaved applications? Or optimize with a mix of well-behaved and poorly behaved applications? |
The front-end application is a J2EE application using QMQ API for JMS. The stress test application is a Java application using WMQ API for Java. We are trying to stress test the back-end (CICS) to know how many transactions per seconds it can handle.
For the moment, I am not trying to optimize the performance of the sending application (J2EE). Unless the test proves that this is where most of the time is wasted.
I do not have access to the J2EE source code (sending application), therefore I cannot see if its poorly written. But if I can prove the back-end (CICS) is able to handle the incoming requests, I may be able to ask the J2EE team to review there code. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 25, 2009 8:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
[quote="Maximus]
The J2EE application we are trying to simulate takes the connection from a pool and therefore need to close the queues otherwise they will never be closed. This is why the java program we built to simulate the J2EE workload is doing the same calls.[/quote]
Queues are closed automatically when the connection is dropped. It may be better to leave them open. Whether subsequent queue opens then have a lower overhead is something that can be measured. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 25, 2009 8:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Maximus wrote: |
| For the moment, I am not trying to optimize the performance of the sending application (J2EE). |
Right. So you actually probably want to make the stress test application perform worse, or as close to as badly as the JMS app does.
So ignore PUT1.
I'm not much on mainframe, so I'd go with Mr. Butcher's advice and increase CHIADAPS and CHIDISPS. There may also be MF specific tuning things on open handles that I'm not aware of - is there a perf support pac for MF? |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 8:15 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| zpat wrote: |
[quote="Maximus]
The J2EE application we are trying to simulate takes the connection from a pool and therefore need to close the queues otherwise they will never be closed. This is why the java program we built to simulate the J2EE workload is doing the same calls. |
Queues are closed automatically when the connection is dropped. It may be better to leave them open. Whether subsequent queue opens then have a lower overhead is something that can be measured.[/quote]
This is interesting. Are you saying that in J2EE, using a connection pool, you can just open queues and never close them and it may end-up being faster for the subsequent open calls on the same queues since they could reuse the opened handle?
I always thought that leaving queue handles open would only waste resources and that at some point no more queues could be opened. Is this assumption false? |
|
| Back to top |
|
|
| Maximus |
| Posted: Wed Feb 25, 2009 8:38 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| mqjeff wrote: |
| Maximus wrote: |
| For the moment, I am not trying to optimize the performance of the sending application (J2EE). |
Right. So you actually probably want to make the stress test application perform worse, or as close to as badly as the JMS app does.
So ignore PUT1.
I'm not much on mainframe, so I'd go with Mr. Butcher's advice and increase CHIADAPS and CHIDISPS. There may also be MF specific tuning things on open handles that I'm not aware of - is there a perf support pac for MF? |
Great. thanks for the advise. I just increase the CHIADAPS and CHIDISPS and another round of test will be done during lunch time. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 25, 2009 8:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You might also consider capturing SMF stats data on the qmgr and cics before and after to validate where the problem actually is, and if your solution actually corrects what you are attempting to correct. Think of this as the scientific method.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
