| Author |
Message
|
| hin3407 |
 Posted: Wed Mar 07, 2007 2:55 pm Post subject: runmqlsr vs inetd.conf for MQv6 |
 |
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
Does anyone have any recommendations, suggestions on which of the two listeners is better for MQv6. From what I heard runmqlsr is the preferred method. We currently use inetd.conf, and we would like to know what the critical differneces are and if there is a general recommendation.
When I mean better, I am looking for
Managability, performance, administration, security,etc.
Thank you. |
|
| Back to top |
|
 |
| mvic |
| Posted: Wed Mar 07, 2007 4:50 pm Post subject: Re: runmqlsr vs inetd.conf for MQv6 |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
For runmqlsr/amqrmppa: deal only with MQ admin commands etc. and avoid having to set/reset inetd when taking MQ downtime eg. for upgrades. Have many channels running as threads in the amqrmppa processes.
For amqcrsta: each thread its own independent process, therefore theoretically more robust and independence between channels. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Mar 08, 2007 1:22 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
also runmqlsr knows if the qmgr is up or not... inetd.conf does not.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bbburson |
| Posted: Thu Mar 08, 2007 6:26 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Mar 08, 2007 7:11 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
I've always thought that the arguement for using runmqlsr, to cut down on the number of amqcrsta processes, is a bit silly. We have several hundred amqzlaa processes running on our development box, so what? And this way, if you have a problem with a channel, you can identify the process ID from the channel status and kill the bugger directly! 
P.S. I know you can have multi-threaded zlaa processes but we have a memory limit of 256Mb per process, which gets blown in one session. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 08, 2007 7:27 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| dgolding wrote: |
| P.S. I know you can have multi-threaded zlaa processes |
This is indeed possible... in fact it's the default to have roughly 60 threads in each amqzlaa0. Each thread in amqzlaa0 serves an application HConn somewhere. |
|
| Back to top |
|
|
| hin3407 |
| Posted: Thu Mar 08, 2007 9:55 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
| What about performance? Is there any known improvements or impacts. We understand the manageability of the processes and the commands, however what about performance of the runmqlsr for connections of applications and transacations. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 08, 2007 3:19 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hin3407 wrote: |
| What about performance? Is there any known improvements or impacts. We understand the manageability of the processes and the commands, however what about performance of the runmqlsr for connections of applications and transacations. |
I don't have access to any data from performance measurements, but I know of no reasons why there should be any difference in performance between the two. Do you have any specific concerns that lead to this question? |
|
| Back to top |
|
|
| hin3407 |
| Posted: Fri Mar 09, 2007 8:23 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
Our performance questions are related to the amount of time an application would connect to a queue. Specifically about connections, and improved throughput.
We seen this from IBM:
The new listener model is one of the major advantages of V5.3. It is a scalable process, and is more efficient than the older INETD single channel process per connection model. The new model, offers less overhead and improved throughput. RUNMQLSR spawns a channel pooling process called AMQRMPPA. AMQRMPPA handles connection by using threads of itself and spawns a new AMQRMPPA process when it reaches it self-imposed thread limit of 64. |
|
| Back to top |
|
|
| bbburson |
| Posted: Fri Mar 09, 2007 9:07 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| And from the administrative standpoint, in WMQv6 the listener can be managed as an object within the queue manager. No more separate process to start when the queue manager comes up. PLUS the listener can now be stopped even when the queue manager is up which can be a major help if you need to cut off external access to the queue manager while troubleshooting. |
|
| Back to top |
|
|
| hin3407 |
| Posted: Fri Mar 09, 2007 9:11 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
How so? (WMQv6 the listener can be managed as an object within the queue manager.)
That sounds pretty interesting.
What is defined? Can you give me an example. |
|
| Back to top |
|
|
| hin3407 |
| Posted: Fri Mar 09, 2007 9:14 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
| I just looked it up in the MQSC guide, im assuming you mean the Define Listener object. |
|
| Back to top |
|
|
| bbburson |
| Posted: Fri Mar 09, 2007 9:15 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| DEFINE LISTENER(....) . . . CONTROL(QMGR) |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Fri Mar 09, 2007 9:16 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
Yes, I;m pretty sure that's what he meant.
D:>runmqsc
5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
Starting MQSC for queue manager TEST.
DEFINE LISTENER(TCP.LISTENER.1424) TRPTYPE(TCP) PORT(1424) CONTROL(QMGR)
1 : DEFINE LISTENER(TCP.LISTENER.1424) TRPTYPE(TCP) PORT(1424) CONTROL(QMGR)
AMQ8626: WebSphere MQ listener created.
START LISTENER(TCP.LISTENER.1424)
2 : START LISTENER(TCP.LISTENER.1424)
AMQ8021: Request to start WebSphere MQ Listener accepted.
DIS LSSTATUS(TCP.LISTENER.1424)
3 : DIS LSSTATUS(TCP.LISTENER.1424)
AMQ8631: Display listener status details.
LISTENER(TCP.LISTENER.1424) STATUS(RUNNING)
PID(4372) STARTDA(2007-03-09)
STARTTI(12.14.39) DESCR( )
TRPTYPE(TCP) CONTROL(QMGR)
IPADDR(*) PORT(1424)
BACKLOG(100)
STOP LISTENER(TCP.LISTENER.1424)
4 : STOP LISTENER(TCP.LISTENER.1424)
AMQ8706: Request to stop WebSphere MQ Listener accepted. |
|
| Back to top |
|
|
| hin3407 |
| Posted: Fri Mar 09, 2007 9:46 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
Any comments on my previous question regarding performance:
Our performance questions are related to the amount of time an application would connect to a queue. Specifically about connections, and improved throughput.
We seen this from IBM:
The new listener model is one of the major advantages of V5.3. It is a scalable process, and is more efficient than the older INETD single channel process per connection model. The new model, offers less overhead and improved throughput. RUNMQLSR spawns a channel pooling process called AMQRMPPA. AMQRMPPA handles connection by using threads of itself and spawns a new AMQRMPPA process when it reaches it self-imposed thread limit of 64. |
|
| Back to top |
|
|
|
|
