| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQSeries Client/OS390 Intermittent long MQPUT/GET resp time |
« View previous topic :: View next topic » |
| Author |
Message
|
| cvj |
 Posted: Tue Sep 03, 2002 12:42 am Post subject: MQSeries Client/OS390 Intermittent long MQPUT/GET resp time |
 |
|
Newbie
Joined: 24 Jun 2002
Posts: 4
|
Hello,
We went live last week with application using MQSeries Client for Stratus and MQSeries for OS/390. Physical connection between the two boxes is over the LAN. Performance in terms of transaction response times is generally better compared to the non-MQSeries (over SNA) set-up it replaced.
However, there are times when performance severely degrades with individual MQPUTs and MQGETs taking half a minute to five minutes to complete. We experienced the same problem in the development/test OS/390 environment. At that time, we resolved this by assigning MQSeries Listener and Queue Manager jobs to higher service class. We are somewhat reluctant to implement the same solution in the production case since this may impact the existing production CICS subsystems.
My question is, what is the recommended service class (SRVCLASS) for the MQSeries TCP/IP Listener (SVRCONN) job? Should it be
(1) the same as VTAM, OS/390 (i.e. highest dispatch priority),
(2) the same as production CICS, or
(3) lower than production CICS but higher than batch jobs?
(2) and (3) above does not eliminate the problem. (We are going to try (1) above tomorrow.)
Any recommendation on the above will be greatly appreciated, including any specific advice on other tuning values (TCP/IP KEEPALIVE?), as well as any tips on possible causes or on how to diagnose the cause of the intermittent long MQPUT/MQGET response times.
Thanks in advance!
regards,
Chuck Jugo |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Tue Sep 03, 2002 1:48 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Gee.... that's not good.
Well how is your LAN workload ?
Second how is your utilization of the PS' that are keeping the SYSTEM.CHANNEL.SYNCQ and other vital system queues.
Third have you analyzed the SMF-performance records, they might give you a clue. Buffers, size of CHIN address space, number of TCB's in the connection and size of log-dsn.
Fourth how often does the QMGR cut a CHECKPOINT/ARCHIVE LOG, if too offen it might influence on performace.
just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| cvj |
| Posted: Tue Sep 03, 2002 8:36 am Post subject: |
|
|
Newbie
Joined: 24 Jun 2002
Posts: 4
|
Jorgen,
Thanks for your response.
Based on our observations, the problem coincides with periods of 100% CPU activity as well as some file transfer (FTP) activity on the OS/390 platform. Although the RMF report on average Channel utilization per hour of the 10 Mbps OSA Card does not exceed 14%, so i'm not sure if we can consider the lan utilization heavy.
Thanks for your pointers above, although for your third suggestion, we plan to turn on trace on the test system to see what particular socket call is taking time.
BTW, the application puts non-persistent messages and do not use the syncpoint option.
Regarding our plan to assign the distributed queuing started task procedure ('xxxxCHIN') to a System Service Class, do you have any recommendations for or against? My assessment is that this should be treated with same level of importance as VTAM or TCP/IP subsystems since this is also part of the communications layer.
regards,
Chuck Jugo |
|
| 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
|
|
|
|
