| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multiple programs getting from the same queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| RB |
 Posted: Tue Jul 24, 2007 8:31 am Post subject: Multiple programs getting from the same queue |
 |
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
All,
We have a 3 tier architecture, where program from the IMS puts to a queue, broker sends to the java app on the AIX platform and send a response back.
When we are running the IMS pgm in single thread we are getting good response times. But when we send in multi thread (using multiple IMS regions) the response time is horrible. When we run single thread, we get an average 300 ms response time and with multiple (10 message region) it is well over one second.
The IMS program after putting the message in to the request queue, listens to the response queue with a timeout period set to 3 seconds. Is there any limit to the number of pgms concurrently listening to a queue? Is it possible for all the 10 programs to actively wait for a get on the response queue? We have alredy noticed lot of CPU time going on during the gets. I am just wondering whether 10 programs trying to do a get is slowing down the entire process. I would appreciate if anyone can help me to understand what is going wrong here.
Regards, |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jul 24, 2007 9:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This question maybe belongs in the mainframe forum - a moderator will perhaps move it.
You do have a very interesting 3 tier architecture - as it's entirely run in reverse to what most people think about as a 3 tier architecture these days! Most people see 3 tier as web(unix)->broker->mainframe->reply.
I'm guessing this is strictly an IMS configuration issue - that you're not setting it up properly to multithread the GETs. But I'm really really not an IMS or mainframe person.
During the long wait time, what does the queue manager show for the IPPROCS on the reply queue?
Also, you can try configuring the ReplyToQueue as a dynamic queue, instead of sharing a single fixed queue between all the threads. This might, I say might give you better performance.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RB |
| Posted: Tue Jul 24, 2007 11:37 am Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
I was thinking like MQ on zOS may be having any restriction on the concurrent "GET"s. The opprocs was always less than 3 during the execution. Is there any setting which limits the number of concurrent gets??
We are using multiple message regions and I think it is working fine (Though the transactions waiting to be executed might be adding to the delay).
We will be using a clustered queue in Production with three queue manager part of the cluster and will be using ReplytoQueues. But in test we have only one queue manager in zOs. But we wanted to do the stress testing with only on queue manager.
Regards,
RB |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jul 24, 2007 2:08 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| MucheIsMyHero |
| Posted: Fri Jul 27, 2007 4:11 pm Post subject: |
|
|
Novice
Joined: 29 Jun 2005
Posts: 14
|
Would you mind posting output from a DISPLAY QMGR command on your z/OS system?
| RB wrote: |
I was thinking like MQ on zOS may be having any restriction on the concurrent "GET"s. The opprocs was always less than 3 during the execution. Is there any setting which limits the number of concurrent gets??
We are using multiple message regions and I think it is working fine (Though the transactions waiting to be executed might be adding to the delay).
We will be using a clustered queue in Production with three queue manager part of the cluster and will be using ReplytoQueues. But in test we have only one queue manager in zOs. But we wanted to do the stress testing with only on queue manager.
Regards,
RB |
|
|
| Back to top |
|
|
| RB |
| Posted: Tue Jul 31, 2007 12:53 pm Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
Here is the information about the queue manager
| Code: |
Queue manager name . . . . :,DG01
, ,
Description . . . . . . . . :,DG01, IBM MQSeries for Z/os - V6,
,.0 ,
Default transmission queue :,DG01.DEFXMIT.QUEUE
Dead-letter queue . . . . . :,DEAD.LETTER.QUEUE
Trigger interval . . . . . :,999999999,,0 - 999999999 milliseconds ,
Max open handles . . . . . :,256 ,,0 - 999999999
Max uncommitted messages . :,100000 ,,1 - 999999999
Expiry interval . . . . . . :,OFF ,, 1 - 99999999 seconds or OFF
, ,
Command level . . . . . . . :,600 ,
Coded character set ID . . :,500 ,
Last alteration time . . . :,2007-07-06 23.30.24,
Monitoring,
,,Queues . . . . . . . . . :,O,,N=None, L=Low, M=Medium, H=High, O=Off ,
,,Channels . . . . . . . . :,O,,N=None, L=Low, M=Medium, H=High, O=Off ,
,,Auto-defined ,
,cluster-senders . . . . :,O,,Q=Qmgr, L=Low, M=Medium, H=High, O=Off ,
Queue accounting . . . . . :,E,,E=Enabled, D=Disabled, N=None ,
, ,
Trace route recording . . . :,M,,M=Message, Q=Queue, D=Disabled ,
Activity recording . . . . :,M,,M=Message, Q=Queue, D=Disabled ,
, ,
Shared queue puts . . . . . :,U,,U=Use queue manager name, I=Ignore ,
Cluster workload,
,,Exit name . . . . . . . :, ,
,,User data . . . . . . . :,
,,Message length . . . . . :,100 ,,0 - 104857600
,,Max used channels . . . :,999999999,,1 - 999999999
,,Queue use . . . . . . . :,L,,A=Any, L=Local
Repository management,
,,Cluster name . . . . . . :,ESBOPR
,,Cluster namelist name . :,
,
Queue manager identifier . :,DG01.B4D8D28A5D166FC3
Channel initiator control,
,,Adapters . . . . . . . . :,80 ,,0 - 9999
,,Dispatchers . . . . . . :,20 ,,1 - 9999
,,Listener restart . . . . :,60 ,,5 - 9999 seconds
,,Trace table size . . . . :,10 ,,2 - 2048 MB
,,Start trace . . . . . . :,N,,Y=Yes, N=No
LU6.2 control,
,,Outbound LU name . . . . :, ,
,,Generic inbound LU name :, ,
,,ARM member suffix . . . :, ,
Channel control,
,,Max current channels . . :,3000,,1 - 9999 ,
,,Max active channels . . :,3000,,1 - 9999 ,
,,Max TCP/IP channels . . :,3000,,0 - 9999 ,
,,Max LU6.2 channels . . . :,200 ,,0 - 9999 ,
,
,,Adopt orphan channels . :,A,,N=No, A=All types ,
,,Adopt orphan checking . :,A,,Q=Queue manager name, N=Network address,
,A=All, 0=None
Channel auto-definition,
,,Exit name . . . . . . . :, ,
TCP/IP control,
,,System name . . . . . . :,TCPIP ,
,,Keep alive . . . . . . . :,Y,,Y=Yes, N=No ,
,,Stack use . . . . . . . :,S,,S=Single, M=Multiple ,
,,IP address version . . . :,4,,4=IPV4, 6=IPV6 ,
,,Outbound port range . . :,0 ,,to . . :,0 ,,0 - 65535 ,
,,DNS registration . . . . :,N,,Y=Yes, N=No ,
,,DNS group name . . . . . :, ,
,,Receive wait time, ,
,, Type . . . . . . . . . :,M,, M=Multiply, A=Add, E=Equal ,
,, Factor . . . . . . . . :,0 ,,0 or 2-99, 1-999999, 0-999999 seconds
,, Minimum . . . . . . . :,0 ,,0 - 999999 seconds
SSL authentication namelist ,
name . . . . . . . . . . . :,
SSL key repository, ,
,, . . . . :,
,
,
,
SSL server tasks . . . . . :,0 ,,0 - 9999 ,
SSL key reset count . . . . :,0 ,,0 - 999999999 ,
, ,
Intra-group queueing . . . :,N,,Y=Yes, N=No ,
,,Put authority . . . . . :,D,,D=Default, C=Context, O=OnlyIGQ, A=AltIGQ
,IGQ user ID . . . . . . :, ,
Event control,
,,Inhibit error . . . . . :,E,,E=Enabled, D=Disabled ,
,,Local error . . . . . . :,E,,E=Enabled, D=Disabled ,
,,Remote error . . . . . . :,E,,E=Enabled, D=Disabled ,
,,Start and stop . . . . . :,E,,E=Enabled, D=Disabled ,
,,Performance . . . . . . :,E,,E=Enabled, D=Disabled ,
,,Configuration . . . . . :,E,,E=Enabled, D=Disabled ,
,,Command . . . . . . . . :,D,,E=Enabled, D=Disabled, N=NoDisplay
,,Channel . . . . . . . . :,X,,E=Enabled, D=Disabled, X=Exception
,,SSL . . . . . . . . . . :,E,,E=Enabled, D=Disabled ,
,,IMS Bridge . . . . . . . :,E,,E=Enabled, D=Disabled ,
|
Regards,
Rijesh |
|
| Back to top |
|
|
| MucheIsMyHero |
| Posted: Thu Aug 02, 2007 4:45 pm Post subject: |
|
|
Novice
Joined: 29 Jun 2005
Posts: 14
|
| RB wrote: |
I was thinking like MQ on zOS may be having any restriction on the concurrent "GET"s. The opprocs was always less than 3 during the execution. Is there any setting which limits the number of concurrent gets??
Regards,
RB |
Just realized that you mentioned only 3 concurrent GETs, yet you referenced OPPROCS. OPPROCS indicates handles that have the queue open to PUT, not GET. How many IPPROCS are open when you run your test? That would tell you how many concurrent GET handles you have. Sorry if this offers little insight, just something I noticed. Good luck. |
|
| 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
|
|
|
|
