| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multiple clients design considerations |
« View previous topic :: View next topic » |
| Author |
Message
|
| aq |
 Posted: Tue Jan 27, 2004 3:38 am Post subject: Multiple clients design considerations |
 |
|
Apprentice
Joined: 20 Dec 2001
Posts: 47
|
Hi
We are about to start project where multiple JMS-clients are connecting to MQ/WMQI for request/reply and one-way datagram communication scenarios. The messages are flowing both ways, meaning that either the JMS clients or the WMQI server will be sending the request/reply and datagrams messages to each other. 1 client is sending and/or receiving about 3 - 5 messages around every 5 - 10 mins. So the amount of messages shouldn't be the problem (atleast from the MQ point of view), the message format is XML and the size of the single message is around 5 - 10 kilobytes.
There are couple questions that we are still little bit unsure:
1. The number of JMS clients/computers are around 900 - 1100, so there will be that number of MQ client connections, how much the MQ can handle the client connections ? Do you think this too much (on Windows 2000 and/or AIX) ?
For performance reasons the client connections should be on all the time, do you think this wise or should they create the client connection only when there is need (in every 5 - 10 mins) ?
2. How well does the WMQI play with dynamic queues or is there way to handle them at all ?
I was wondering about how the request/reply queues should be handled, like a one per JMS client or just one reply queue for them all and then the JMS clients just find the right messages with message selectors from the one "communal reply queue". Any recommendations for working solution here ?
Regards,
Alan |
|
| Back to top |
|
 |
| kirani |
| Posted: Tue Jan 27, 2004 10:41 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I am assuming that all client applications will connect to Broker queue manager.
You can have any number of Clients applications connected to a server queue manager, up to the level determined by the server system resources. Also, there is a limit to the number of outstanding connection requests that can be queued at a single TCP/IP port, I think for Windows platform the limit is 100. There is a MAXMSGL parameter for the MQ Client connection channel, which controls the maximum length of the message that can flow between Client and Server. This is all documented in Websphere MQ Client manual.
| aq wrote: |
For performance reasons the client connections should be on all the time, do you think this wise or should they create the client connection only when there is need (in every 5 - 10 mins) ?
|
Either way is fine. Calling MQCONN multiple times will hae minimum impact on your performance. It's good practice to connect to the queue manager only once and then use the same connection for subsequent PUTs and GETs.
| aq wrote: |
2. How well does the WMQI play with dynamic queues or is there way to handle them at all ?
I was wondering about how the request/reply queues should be handled, like a one per JMS client or just one reply queue for them all and then the JMS clients just find the right messages with message selectors from the one "communal reply queue". Any recommendations for working solution here ?
|
WMQI can GET/PUT messages from/to dynamic queue's. But how will you set the queue name in MQInput node for MQGET?? I think, you should have single RQST/RPLY queue and have the clients read the reply message using Msg-ID/Correl-ID combination from single queue.
Hope this helps.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
Last edited by kirani on Tue Jan 27, 2004 1:23 pm; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 27, 2004 12:22 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would go with one static request queue, and multiple dynamic reply queues.
Going with one reply queue could cause bottlenecks if there are lots of replies going onto it at once. If you have a thousand replies, and the first client tries to get at the last reply, it will take a while.
You can tell WMQI to set the DestinationList for the MQOutput node to be the ReplyToQueue (which the client app should have populated when it made the request with the name of it's dynamic queue). Or you can use the MQReply node to make it easier.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mverh |
| Posted: Tue Jan 27, 2004 2:18 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
I would never allow 1000+ clients to client connect to my broker queue manager. I would deploy a separate WMQ server and have the clients connect to it (client concentrator) and then have this server connect to the broker queue manager through regular dqm or cluster channels. This way you have a better architecture for scaling. What will you do when client # 1001 causes resource problems on your broker, by deploying client concentrators you can easily spread the client connections across multiple client concentrators if demand dictates. Also by using the client channel table you can get some limited form of failover if one of the client concentrators dies.
I don't know exactly how you could have dynamic request queues, your request queues will have to be static. I would also recommend using separate reply to queues for each client. If possible make them permanent dynamic if the name assigned to them is predictable across client application restarts, this way you can reduce some of the overhead of allocating the queue when the application initializes.
Note there have been some improvements lately in dynamic queue management but I have seen problems where 1000's of ghost queues end up being allocated and never go away even though they are temporary dynamic.
_________________
Marc Verhiel
IBM Canada Ltd. |
|
| Back to top |
|
|
| aq |
| Posted: Wed Jan 28, 2004 11:42 pm Post subject: |
|
|
Apprentice
Joined: 20 Dec 2001
Posts: 47
|
Thank you for excellent answers, they cleared really bunch of my thoughts !
So the JMS client application connection part seems to be quite clear now. The production system will be running probably in AIX, so I should next find out the what kind of server it will be and what the limit's of those outstanding connection request per tcp/ip port in AIX are, like Kiran explained to me.
Good thing to hear was that the MQCONN call doesn't have so big performance impact that I had thought and as I assumed from the answer there shouldn't be problem either to keep connections open (as long there are server resources left). I think that the JMS client applications will be holding the connection open, until the application is shutdown or the connection is not valid anymore (and have to be reconnected).
Marc's notice about making separate WMQ server(s) for concentrating the client connections to them, and not directly to the WMQI was very good observation. I think we should definetly think out system design in this way.
For the WMQI reply queues, I'm still wondering what could be right solution, I now have 3 different choices for them in mind:
1. Just one reply queue for all the clients, from where the clients will pick the messages intended for them. Simple to do it, but I'm little bit worried about the performance in this choice, just like Jeff stated also.
2. Couple ten reply queues (for example by geographical areas), so kind of same solution than previously one, but at least not all the reply messages are in same queue (ofcourse I should find out some estimate about messages per/area before hand this to work)
3. For each client (client is one office location) it's own reply queue, works well I think, but there will be around 1000 queues. I wonder will there be some problem in administrating them 
All these three solutions should work just fine with WMQI, I think ?
Any other solution for reply handling ? (the message traffic was 2 way, so the initial request message can be sent either from the WMQI message flow or from the JMS client)
Regards,
Alan |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Jan 29, 2004 12:21 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I see Marc's point regarding resource problems on the broker queue manager, but the resource contention will happen on the server, so all the queue managers on that server will get affected (including the Broker queue manager). I don't see a reason why you cannot scale the application using Broker queue manager.
If the "client connection queue manager" was running on a different physical server then it would make sense to have client app connect to that queue manager instead of Broker queue manager.
We have developed similar application in our environment where we have around 800 - 1000 clients (GUI) making calls to MQ via mid-tier (COM Architecture) components. We have a common Component, which puts request messages on RQST queue and reads Reply message from Reply queue and delivers them to the caller component. In this scenario, I don't see any performance overhead in getting messages from queue using CorrelId. In fact I proved it by writing a small program, which reads 10000th message from the queue using Correl-Id and it took less than a second. I didn't want to use dedicated reply queues or dynamic reply queue because they add administration overhead.
It'd be a good idea to develop a prototype and test out which architecture fits/performs better.
Good luck!
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| mverh |
| Posted: Thu Jan 29, 2004 4:29 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
It's not clear in my post so I will clarify it here...the client concentrator would indeed be a physically separate box from the broker server. I wouldn't instantiate another queue manager on the same box as the broker queue manager.
_________________
Marc Verhiel
IBM Canada Ltd. |
|
| 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
|
|
|
|
