ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportPerformance with one vs Multiple Server connection channels

Post new topicReply to topic
Performance with one vs Multiple Server connection channels View previous topic :: View next topic
Author Message
siljcjose
PostPosted: Mon Dec 19, 2016 6:34 am Post subject: Performance with one vs Multiple Server connection channels Reply with quote

Apprentice

Joined: 18 Aug 2005
Posts: 27

Hello MQ Experts,

I have number of client applications connecting to a queue manager. The number can go upto 100 instances at a given time.

My question, would there be any performance improvements for the client, if they are given different set of Server connection channels to connect. Say I restrict 20 instances per channel. ie 5 different channels distributed among the application for 100 instances of connections to the queue manager.

Do any one have any suggestion or experience around this with respect to performance, one channel with 100 instances or 5 with 20 each.

Thanks
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Mon Dec 19, 2016 1:56 pm Post subject: Reply with quote

Shaman

Joined: 17 Nov 2005
Posts: 748
Location: New Zealand

I can't think of a reason why the actual number of CLNTCONN or SVRCONN definitions should make a significant different to performance.

What can make a significant difference is the amount of conversation sharing between the channels instances. In other words the ratio between Channel Instances and TCP/IP sockets. Less sockets can mean less over-head of SSL Handshakes and less resources but it will also mean more context switching and locking. If you are just looking for best channel through-put then having no sharing is probably best. However, this has been discussed many times on here before so I won't go over it again,

Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
mvic
PostPosted: Mon Dec 19, 2016 7:19 pm Post subject: Re: Performance with one vs Multiple Server connection chann Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

One channel def with 100 instances, will perform the same as 5 channel defs with 20 each, assuming they are coming from 100 separate client programs. As PaulClarke says, the story is a little different if connections are being shared.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Dec 20, 2016 2:52 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7305

The SVRCONN channel definition is just a template for when an actual channel instance needs to be started. As Paul and mvic have stated, makes no diff if you start your 100 channel instances off one "template", or off 5 different ones, or off 100 different ones.

Define additional SVRCONN channels as needed, for when you need different attributes for different instances.

The exception to the above is Shared Conversations, again as Paul and mvic mentioned.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportPerformance with one vs Multiple Server connection channels
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.