| Author |
Message
|
| kelly |
 Posted: Thu Feb 21, 2002 6:34 am Post subject: |
 |
|
Newbie
Joined: 20 Feb 2002
Posts: 2
|
I was recently asked to approve a MQ based solution that was designed to handle 24,500 messages per hour initially and ultimately scale to 100,000 per hour. The comms infrastructure between the source and destination would be a frame circuit with a guaranteed CIR etc i.e. a WAN. The messages are time critical with a validity of no more than about 20-25 seconds. I was presented with two options:
(A) MQ Client – MQ Server > the application/client would simply put the messages on the ‘server’ across the WAN and the application would determine if this was successful or not
(B) MQ Server – MQ Server > utilizing remote queues etc. whereby the task of getting the message(s) across the WAN would be taken care of by MQ and MQ would indicate if there was a problem
To my surprise the technical and development teams suggested that MQ Client – MQ Server option was best. My investigations indicated that an MQ Server – MQ Server set-up was best but I couldn’t really put forward facts to support my case, the only thread of evidence I had was that an engineer from another firm said MQ Server – MQ Server communications were 'optimised' but besides that I can’t actually find any documents etc. on the WEB or from IBM which clarifies the position. To summarise:
What are the performance and reliability differences between MQ Client – MQ Server and an MQ Server – MQ Server set-up?
Which is best over a WAN?
Any comments much appreciated.
|
|
| Back to top |
|
 |
| StefanSievert |
| Posted: Thu Feb 21, 2002 11:37 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Kelly,
my two cents on your question:
First of all, you write that your messages have a limited validity of 20-25 seconds. Why would a client then need to know if a message has reached its destination?
It sounds like you could put the messages as non-persistent with Expiry set, so your producers can be implemented as fire and forget. Or do you need to take action if the time limit has been reached and the message has to be processed otherwise?
A server-server implementation provides some benefits over a client-server architecture:
1/ Your applications don't have to deal with network problems. The message channel agents will handle any retry processing for you (depending on the reliability of your WAN, this can be very advantageous)
2/ It decouples your application from network latencies. In a client-server scenario, your client will not get control back from an MQPUT until the message has been put on the remote queue and the response from that has been travelled back to your client.
3/ It decouples your client from remote queue manager availability (might not apply in your case because of your short message lifetime)
4/ It enables you to do XA resource coordination with a database, which is not supported with the MQ Client
5/ It uses less (WAN) network and remote queue manager resources, if you have multiple clients connecting (server=concentrator)
6/ It can improve throughput by batching messages produced by multiple clients
7/ Systems management might be easier on one server than on n clients
I would use a server-server connection, especially over a WAN. It gives you a lot more flexibility and openness.
Have you looked at the performance support pacs on the IBM website? Maybe you can find some comparisons of raw throughput between server-server connections and client connections.
As I said, just my 2 cents but maybe other people can add something so you'll have a buck by the end of the day! 
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| beernink |
| Posted: Thu Feb 21, 2002 4:30 pm Post subject: |
|
|
Newbie
Joined: 15 Jan 2002
Posts: 8
Location: NZ Post
|
We have a very similar situation with over 1200 MQ clients connecting from a branch network over the WAN to central MQ servers. We use this for large volume online transactions, where we need responses within seconds. We are having problems with this setup, but mainly because of having the MQ servers running on OS/2 for legacy reasons.
We have gone through an architecture review, where we came to the same conclusion that you were given; that we can safely continue with this MQ client-server set up as long as we move off OS/2 for the MQ servers.
The MQ client-server set up has more restrictions/less flexibility than the server-server option, but typically these don't come into play for (near) realtime transactions. The main thing to understand though is that obviously there is no message queueing at the client end: it creates the message at its remote server. So basically it is an RPC type call, which can have issues over a WAN. With an MQ client, it puts more responsibility on the application to ensure that the MQ server connection has not dropped.
Feel free to contact me for more feedback.
Regards
Ron Beernink |
|
| Back to top |
|
|
| jfluitsm |
| Posted: Mon Feb 25, 2002 1:14 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
It all depends on the number of sources.
Are the sources a number of servers it's best to use a server-server scenario.
Are the sources a lot of workstations, the client-server is the best scenario, with a server-server scenario you need a licence for every workstations, and you need to administrate all these queue-managers.
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| kelly |
| Posted: Mon Feb 25, 2002 3:41 am Post subject: |
|
|
Newbie
Joined: 20 Feb 2002
Posts: 2
|
| The number of sources is very limited. Initially there will only be one source but in the future this may increase to 5. The cost of licenses is not critical within the overall context of the solution, what is paramount is the scalability, robustness and speed of the solution. |
|
| Back to top |
|
|
| chksi |
| Posted: Mon Feb 25, 2002 7:22 am Post subject: |
|
|
Newbie
Joined: 24 Feb 2002
Posts: 1
|
We have a client->server architecture over the WAN in place right now. It is a Sun Solaris client communicating with a Server on AS400. We have 960 active clients, talking to two different QMs in different locations. It is a "time-critical" application. Our request message expiry is set to 15 sec. This is used in a telephony application when a user is on a phone in real time. Our critical requirement is not to hold a caller for more than 6 sec without a "Hold On" message. The problem with this setup is with MQConnect which sometimes takes about 8-12 sec to execute. PUTs & GETs are almost instant.
To overcome this issue we pre-connect prior to business day start and keep connections open throughout the whole day. Then terminate connections at the end of a day.
It is also seems to be a burden on AS400 resources, though the application has been running for over two years now. But overall it is a stable application.
From what I know IBM does not "guarantee" the delivery of a message in client->server setup, plus there is no support provided for client if you come to a halt in your development.
For our next application we are redesigning to go local MQClient->local MQServer -> remote MQServer.
I personally favor "server -> server" setup as being very stable and robust, plus as mentioned earlier in the posts it takes a lot of overhead from the application side to handle all network failures. Connection between the servers is managed by the QMs and is there when you need it. And connection between local client and server (same box) should not be a problem. In addition, if there is a failure of a local QM we go to another QM on the other machine for redundancy purposes.
The reason we went with client->server in a first place was due to a cost issue and resource limitation on Sun boxes. Now we have an enterprise lisence with IBM, so it is no longer an issue. We added more juice to Sun boxes as well.
This is my two cents. |
|
| Back to top |
|
|
| victor1998 |
| Posted: Thu Jan 20, 2005 3:13 pm Post subject: Re: Client-Server or Server-Server over WAN |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
Hello,
I mee the same problem. The license is not the problem for the project. I am designing an architecture for integrating J2EE Applications with Mainframe Applications by using Weblogic Server and Websphere MQ. It is mission critical and time critical. Need HA.
WLS -> MQ QM1 -> MQ QM2 -> Mainframe.
I am planing to use local connection between WLS and MQ QM1. But I was told that it did not workable because MQ could not handle the memory leak when using IPC for local connection. Under high volumn requests, MQ will use out the resource and make Weblogic Server die.
Could you please let me know whether it is correct?
I could not find any documents from IBM MQ documents to clarify in what scenario I can use MQClient or MQServer, what scenario I can use either of them. Do you know where I can find these documents?
Thank you very much for any help.
Regards,
victor |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Feb 06, 2005 11:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Server to Server connections have more options for controlling batch size, batch interval and that sort of thing (effectively unit of work sizing for MQ itself).
With client channels, you need the application to use syncpointing and decide the commit interval to take advantage of "batching".
Having every message as a separate unit of work will make MQ do more I/O to commit each message to the queue one at a time.
Probably less impact if non-persistent messages and "fast" channels.
You may get more "parallelism" with more channels (usually the case with using client connections, but maybe not in your case).
If the applications are tightly coupled and very time sensitive - then the fewer queue managers involved the better perhaps, I would say. |
|
| Back to top |
|
|
|
|
