It may be simpler to have the customer connect as a client to the local queue manager in Germany and get the advantages of the sdr/rcvr channel pair.
Ralph C Jones -----Original Message----- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 1:56 PM To: [EMAIL PROTECTED] Subject: Re: MQ Channel Communication Overhead and Limited Bandwidth---multiple channels Yes, the messages are persistent, I understand that causes additional throughput issues because of the logging of messages. I would however, like to eliminate the bandwidth issue before I go off "tweaking" my linear logs. One point to remember is, ALL of our customer base uses persistent messaging (and they all have similar message size) and none of them have complained of pour throughput. One simple thing to do, that surely will help is using sender / receiver channels instead of the current client. This whole thing was set up long before I came to work here, I had no idea they owned a queue manager until two days ago. Thanks for the feedback! Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: MQ Channel Communication Overhead and Limited List Bandwidth---multiple channels <[EMAIL PROTECTED] .AC.AT> 09/08/2003 01:33 PM Please respond to MQSeries List Are they and do they have to be persistent???????????????????? >From: Richard Jackson <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQ Channel Communication Overhead and Limited >Bandwidth---multiple channels >Date: Mon, 8 Sep 2003 12:11:48 -0400 > >Bill > >I know that this is an apples to oranges comparison but we've found that 3 >Sender channels between 2 full Qmanagers >gets the best throughput. > >If > >1 channel =100% > >2 channels =150% > >3 channels =177% > >4 channels =125% at this point MQ sends less data than 2 channels. > >This was 2 ZOS Qmanagers at 5.2 level with SCON connected TCPIP channels >between to sites. > >1500 byte messages with a batchsize of 50. > >This is still far far below the throught put you would get if you blocked >the messages. > > > >Richard Jackson >SIAC - >CICS/MQ Systems > > > > > Bill Anderson > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > TA.AERO> cc: (bcc: Richard >Jackson/SIAC) > Sent by: MQSeries Subject: MQ Channel >Communication Overhead and Limited Bandwidth > List > <[EMAIL PROTECTED] > n.ac.at> > > > 09/08/2003 11:06 > AM > Please respond to > MQSeries List > > > > > > >I have a customer in Germany, who is displeased with the throughput he is >getting with his client connection to my server in Atlanta. Please see the >encrypt from an email I received from him below. > >Relating to our 32Bit-Frame-Relay-Connection between Germany and Atlanta, >I've some more questions. > >1. 240KB a minute is the theoretical limit of the bandwidth > >2.1 with big messages (e.g. 2397 bytes) we reach following limits: >2.2 from Germany to Atlanta (MQPUT) >2.3 90 msgs per minute => 210 KB bandwidth >2.4 from Atlanta to Germany (MQGET) >2.5 82 msgs per minute => 191 KB bandwidth > >3.1 with small messages (e.g. 288 bytes) we reach following limits: >3.2 from Germany to Atlanta (MQPUT) >3.3 160 msgs per minute => 45 KB bandwidth >3.4 from Atlanta to Germany (MQGET) >3.5 116 msgs per minute => 33 KB bandwidth > > >Now, the customers assumption is that the problem is with the queue manager >in Atlanta, I am not convinced he is correct. I know there is a >communication over head for using an MQ channel. I believe it is just over >1500 K, but I can't find the exact number in the manuals. Does anyone >happen to know what it is? > >The customer currently connects as a client, but they do run a full queue >manager. I do believe building them a sender / receiver pair of channels >might help some, but what they are asking is multiple channels. If >bandwidth is the problem, more channel won't help much I'm sure. > >Any help would be appreciated > >Thanks > >Bill Anderson > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > > > >----------------------------------------- >This message and its attachments may contain privileged and confidential >information. If you are not the intended recipient(s), you are prohibited >from printing, forwarding, saving or copying this email. If you have >received this e-mail in error, please immediately notify the sender and >delete this e-mail and its attachments from your computer. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ Use custom emotions -- try MSN Messenger 6.0! http://www.msnmessenger-download.com/tracking/reach_emoticon Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
