| Author |
Message
|
| noles321 |
 Posted: Thu Apr 20, 2006 7:15 am Post subject: Design question for Temp Dynamic queue |
 |
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
This is a proposal. Just looking for thoughts of possible pit falls. Thanks in advance.
Here is the scenario. We have 6 farms of 500 windows MQ clients that each attach to their own AIX queue manager. The AIX queue manager acts as a HUB and passes the requests to an 8 processor TPF complex using MQ. TPF is a rare breed, but for this example just think of it as a loosly coupled mainframe complex of sorts... (thats the best way I can describe it) The application is a very high volume application that sends a request from the client through the hub to TPF. TPF then goes to other systems and collects the data and passes it back to the AIX hub. The application is only valid the a small interval of time say 20 seconds as a user is waiting for the data and if it hasn't been received in that time the application services the next request. Is it valid to use a temporary dynamic reply to queue for the client application to wait for the response. This seems to be a natural fit for what we need. However, my concern is that of overhead as I said the volume is very high. Any thoughts on what kind of volume limitations would cause a problem would be helpful. I also would be having an application that serviced the dead letter queue since an occasional message would come back later than the GET with Wait. Can anyone point me to a white paper with performace information. Thanks. All thoughts are welcome
jeramy |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Apr 20, 2006 10:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Of those 500 clients, how many would be concurrently waiting for a message?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Apr 20, 2006 10:28 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| PeterPotkay wrote: |
| Of those 500 clients, how many would be concurrently waiting for a message? |
and, of course you can only use tempDyn queues if the response message in non-persistent.
What is the lifespan of these clients? Do they start-up in the morning and then service the requests all day long? Or is their lifespan just one request.
If they have short lifespans and there is a "handle" that is associated with each client (like username, machine name...), then you can have the client re-use a permDyn queue that is opened the first time they make a request and then "re-used" for subsequent requests.
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 20, 2006 10:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm leaning towards mesages with Expiry, and a single plain old local reply q that the applications all share by using Get by Correl ID.
Orphaned messages just expire, you can track daily volume to see how many messages you are moving, etc.
But if all 500 are working at the same time, then I would consider the dynamic queues, or maybe make 10-50 regular local reply queues and have the clients randomly use those.
I dunno, just never a big fan of dynamic queues. Hard to audit what's going on, messages hit DLQs when they are late, app doesn't clean them up and you have 5 million orphaned dynamic queues. Yes, obviously they can work just fine, but I would rather avoid them IMHO.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JT |
| Posted: Thu Apr 20, 2006 10:51 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
...........and then there would be no real need for the DLQ hander to handle late msgs since the msgs would just expire on the queue:
| Quote: |
| I also would be having an application that serviced the dead letter queue since an occasional message would come back later than the GET with Wait. |
|
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Apr 20, 2006 10:51 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| I dunno, just never a big fan of dynamic queues |
Peter, dynamic queues in general, or only Temp dyn queues? The problems you cite only apply to tempdyn. PermDyn are a nice easy way to allow apps to create "real" queues "on the fly" (but, of course, could also be subject to abusive behaviour)
_________________
-wayne |
|
| Back to top |
|
|
| noles321 |
| Posted: Thu Apr 20, 2006 10:56 am Post subject: Thanks |
|
|
Apprentice
Joined: 15 Nov 2004
Posts: 43
|
Peter,
All 500 will generally be active at all times. The messages are non peresistent and only valuable for a few seconds. I am also considering using one reply queue and getting the message based upon correlation ID. Is there any problems with having a large number of servers connected to a queue waiting for his response? The response has to be received by the server who sent the query.
Thanks.. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Apr 20, 2006 11:14 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
I would think that 500 processes all running a selective MQGET going against the same queue would not perform very well at all.
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 20, 2006 12:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| wschutz wrote: |
| I would think that 500 processes all running a selective MQGET going against the same queue would not perform very well at all. |
but of course as with any performance question, its all relative. An app that takes 10 milliseconds to get a message is 10 times (oo, wow, TEN times faster!!!  ) than one that takes 100 milliseconds, but if the end user expects a response in under 15 seconds because of all the other components involved, who cares?
500 is quite a lot though. Worth doing some tests in my opinion. How is the QM's overall performance going to be constantly creating and deleting all those dynamic queues? Sure, the MQGET may be faster, but is the MQOPEN, when the dynamic q is created, going be much slower? (performance in this area got significantly better in 5.3).
Are the MQClients long lived? Can they open up a dynamic q when they first start up in the AM, and then reuse it all day?
Or how about can you make 50 plain local reply queues, and due to a naming standard, the clients are rather evenly distributed among them? 10 clients sharing a q is certainly no problem at all.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 20, 2006 2:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You did not specify if the apps are on WAS.
WAS uses pools as well for dynamic queues.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
