| Author |
Message
|
| mvic |
 Posted: Fri Mar 09, 2007 9:51 am Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hin3407 wrote: |
| Our performance questions are related to the amount of time an application would connect to a queue. |
Why is this a concern? All channel programs remain connected for as long as they need to be connected, and then they disconnect. Maybe I misundersand the cause for concern here? (Bear in mind, by the way, that apps connect to queue managers. When they've connected to queue managers, they open queues. It's worth being consistent with the language for sake of clarity). |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Fri Mar 09, 2007 10:47 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
my guess is that the question is related to performance figures of MQCONN and MQOPEN which are relatively 'expensive' calls in terms of performance and whether the changes to the listener process have affected these numbers in a positive way?
i.e. applications that connect, open, put1, close, disconnect perform 10% better... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| hin3407 |
| Posted: Fri Mar 09, 2007 10:50 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
| Sounds like you are indeed familiar with what I am asking, whey you said 10% better, is that specific for that sequence using the runmqlsr for the listener? |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Mar 09, 2007 10:54 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
the 10% is an example, but is a figure I mean for this sequence comparing using inetd.conf versus the improved listener process for example
or the 'old' 5.2 listener versus the new 5.3 listener, whatever you like.
of course there are more scenarios, but this is the one that is most affected by the listener because of the many MQCONN,...,MQDISC calls.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Mar 09, 2007 6:21 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Michael Dag wrote: |
| of course there are more scenarios, but this is the one that is most affected by the listener because of the many MQCONN,...,MQDISC calls. |
(Confused) So, is this saying runmqlsr/amqrmppa setups connect disconnect more than amqcrsta? I don't think this is so. Non-MQI channels connect when they start up and disconnect when they end. What am I missing? |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Sat Mar 10, 2007 2:42 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| mvic wrote: |
| Michael Dag wrote: |
| of course there are more scenarios, but this is the one that is most affected by the listener because of the many MQCONN,...,MQDISC calls. |
(Confused) So, is this saying runmqlsr/amqrmppa setups connect disconnect more than amqcrsta? I don't think this is so. Non-MQI channels connect when they start up and disconnect when they end. What am I missing? |
I am not the one asking the original question, I am just guessing at what hin3407 is after.
my guess is he/she wants to know wheter the new runmqlsr/amqrmppa improves performance of client applications performing MQCONN, MQOPEN, MQPUT1, MQCLOSE, MQDISC
since the process runmqlsr/amqrmppa itself is rewritten/improved, does it also improve the overall perfomance of the above mentioned scenario.
I hope I made my point clear and the questions remains whether my guess of what hin3407 is after was right...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Aug 20, 2007 7:01 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
Can I assume that this means that IBM recommends runmqlsr over inetd for all versions from MQ 5.3 on? |
|
| Back to top |
|
|
| hin3407 |
| Posted: Mon Aug 20, 2007 7:10 am Post subject: |
|
|
Centurion
Joined: 17 Oct 2006
Posts: 120
|
That is correct, IBM is recommending the use of the runmqlsr over the inetd.conf.
Especially now with V6.x the listener will automatically start/stop with the Qmgr startup / shutdown. |
|
| Back to top |
|
|
| mqdev |
| Posted: Fri Aug 31, 2007 12:52 pm Post subject: Why runmqlsr is better then amqcrsta? |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Multi-thread (runmqlsr) vs multi-process (amqcrsta) is the question here. As to which is optimal, depends on the context. In an earlier job, I have been in an environment wherein a QM - lets call it QMA, was hosting a Cluster Q in a 1000+ QM Cluster. Every member of the cluster was sending an occasional message to this specific Cluster Q. After a prolonged outage, when the QMA came up, all 1000+ QMs started trying to communicate with QMA. We were then setup through inetd as a result of which, suddenly there were a 1000+ amqcrsta processes to contend with. The server proformance exponentially degraded which resulted in more amqcrsta processes being spawned (due to Channel Retries). To cut a long story short, the server crashed.
We then switched over to runmqlsr and have ever since lived happily!
On the other hand, inetd has a better chance, configuration-wise as we do not need to ensure that a separate process is started and is alive all the time (remember in pre v6.0, runmqlsr is a separate process other then the QM processes and as such needs to be specifically started). With v6.0 however, this is integrated into the QM and can be configured to start with the QM - so this problem is solved as well! So threaded-listener is the way to go!
-mqdev |
|
| Back to top |
|
|
| dutchman |
| Posted: Wed Sep 26, 2007 3:55 am Post subject: |
|
|
Acolyte
Joined: 15 May 2001
Posts: 71
Location: Netherlands
|
Just to add another note to this discussion...
I had an MQ channel exit that was running fine under Redhat Linux, MQ V6.0.1.1 and V6.0.2.2 with the runmqlsr - still 32 bit.
This same exit was also running fine under Solaris 8, MQ V5.3 CSD 11 using INETD. This server was then upgraded to Solaris 10, MQ V6.0.2.1 with runmqlsr ... and 64 bit...
... the exit stopped working. It would start fine but after a few days users reported rc2059 and the only way to resolve it was to kill the queue manager, remove the exit.
Response from IBM: when moving from INETD to runmqlsr, the assumption is that the exit is 'threadsafe'. This problem has occurred not just with my exit; but with another one as well ... different code; developed by another team...totally unrelated.
One thing they have in common: they both read a file to get a list of IP addreses.
Anyway... something to be aware of ... Ruud |
|
| Back to top |
|
|
|
|
