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 Index » General IBM MQ Support » Load Balancing Client Connections and their Performance.

Post new topic  Reply to topic
 Load Balancing Client Connections and their Performance. « View previous topic :: View next topic » 
Author Message
nhenshall
PostPosted: Fri Jan 26, 2018 3:07 am    Post subject: Load Balancing Client Connections and their Performance. Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

Hi

Great forum, I never usually need to post a question but this is one of those problems...

I have a bunch of clients that are currently connecting to an MQ QM on a windows server. The new project has been to have 2 MQ QMs, each on Linux server and balance the workload 50/50.

This is to be done by using the file AMQCLCHL.TAB (CCDT) on the client with the CLNTCONN definitions containing CLNTWGHT(50) and AFFINITY(NONE). So the client will send one request to QM1, the next to QM2..

This works. The vendor who supplied the clients has a log file which shows the response times and this is where we fall down: We've gone from 405ms response to 1405ms, thereabouts. about one second extra.

We've done more tests, a CCDT with linux QM1, another with just QM2, and another with both but CLNTWGHT(0) and AFFINITY(PREFERRED). Effectively the last knocks out the notion of the load balancing but at least gives us the security of having a fallback. They all have a low response time.

So my question is this: Is 1 second extra something that other people have observed for a load balanced setup ? We do have network loadbalancers for other applictions, but this one doesn't have that kind of budget.

For info, the client is 7.0.1.3, the server is 7.5.0.6

Thanks
Neil
Back to top
View user's profile Send private message
zpat
PostPosted: Fri Jan 26, 2018 5:26 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Upgrade your MQ clients to a supported level to start with.

Check out if any DNS resolution delays.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
nhenshall
PostPosted: Fri Jan 26, 2018 5:44 am    Post subject: Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

Quote:

Upgrade your MQ clients to a supported level to start with.


Unfortunately, our hands are a bit tied on that one. I asked the vendor about this and was told that it has to be done "in place" meaning somebody has to take a tour of the country. You'd think in 2018 we'd be more advanced...



Quote:

Check out if any DNS resolution delays.


The connection names are in IP address + port format, so that should bypass that issue I'd think.
Back to top
View user's profile Send private message
zpat
PostPosted: Fri Jan 26, 2018 6:22 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

In which case, examine every fixpak since 7.0.1.3 for any issues in this area.

Because if there is no reasonable explanation for the delay - and no issue with pinging the same server hosts (from the same client hosts) outside of MQ, I would suspect a bug.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
nhenshall
PostPosted: Fri Jan 26, 2018 6:28 am    Post subject: Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

I will do that actually. I hadn't thought of that.

I asked IBM who replied that they don't guarantee that load balanced across 2 QMs is as fast as using 1 QM 100%. But at the same time, they don't (yet ?) have a firm idea of how much longer it should take.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jan 26, 2018 6:32 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

How many CLNTCONN definitions are in your CCDT? 5, 10, 50, 100? If I recall correctly, the CCDT is searched alphabetically; and each CLNTCONN definition is tried 9 times before the next one is tried.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
nhenshall
PostPosted: Fri Jan 26, 2018 6:38 am    Post subject: Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

Quote:

How many CLNTCONN definitions are in your CCDT?




There are 2 Client connections in the CCDT. One for QM1 using channel SVR.01 and another for QM2 using channel SVR.02

So in theory, the client should connect to QM1 first.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jan 26, 2018 7:23 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Post your SVRCONN definitions.

Any errors logged in the error log files on MQ client? MQ Server?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
nhenshall
PostPosted: Fri Jan 26, 2018 8:23 am    Post subject: Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

Quote:
Post your SVRCONN definitions.

Code:

QM01:

   CHANNEL(SVR.01)                         CHLTYPE(SVRCONN)
   COMPHDR(NONE)                           COMPMSG(NONE)
   DESCR( )                                DISCINT(0)
   HBINT(300)                              KAINT(AUTO)
   MAXINST(999999999)                      MAXINSTC(999999999)
   MAXMSGL(4194304)                        MCAUSER(CO_10MQ)
   MONCHL(QMGR)                            RCVDATA( )
   RCVEXIT( )                              SCYDATA( )
   SCYEXIT( )                              SENDDATA( )
   SENDEXIT( )                             SHARECNV(10)
   SSLCAUTH(REQUIRED)                      SSLCIPH( )
   SSLPEER( )                              TRPTYPE(TCP)

QM02:

   CHANNEL(SVR.02)                         CHLTYPE(SVRCONN)
   COMPHDR(NONE)                           COMPMSG(NONE)
   DESCR( )                                DISCINT(0)
   HBINT(300)                              KAINT(AUTO)
   MAXINST(999999999)                      MAXINSTC(999999999)
   MAXMSGL(4194304)                        MCAUSER(CO_10MQ)
   MONCHL(QMGR)                            RCVDATA( )
   RCVEXIT( )                              SCYDATA( )
   SCYEXIT( )                              SENDDATA( )
   SENDEXIT( )                             SHARECNV(10)
   SSLCAUTH(REQUIRED)                      SSLCIPH( )
   SSLPEER( )                              TRPTYPE(TCP)


Quote:

Any errors logged in the error log files on MQ client? MQ Server?

No, no errors in the logs.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Jan 26, 2018 11:49 am    Post subject: Reply with quote

Grand Master

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

Are yo connecting and disconnect for every request ? That was never the intention of CLNTWGHT. CLNTWGHT was for cases where you have 1,000 client machines and want to give them all the same CCDT and have the workload spread across your servers. From any single machine the workload is not spread but from across all your clients you see an even workload.

Your case seems more suitable to either MQ clustering or client based servers to me.

MQ Clustering allows an application to issue a series of PUTs and each message is round-robined around the list of available Queue Mangers.

Or you could do it on the getting side. Have the applications put to a single queue and then have server applications on two different machines consume those messages over a client link. This has the advantage that rather than just splitting the traffic 50/50 the messages are consume by whichever machine has available horsepower.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
nhenshall
PostPosted: Fri Jan 26, 2018 1:06 pm    Post subject: Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

Quote:

Are yo connecting and disconnect for every request ? That was never the intention of CLNTWGHT.



Hi Paul, Yes, it's an application that reconnects for every request. Logon, MQ connect, put/get disconnect. Customer enquiry. MQ Connect, put/get disconnect. and so on.

We have other applications which connect a client on Monday and disconnect.. actually maybe never !

So this method of load balancing isn't the way to go in terms of performance ? So plan B then ? QM1 as primary and QM2 as fallback ?
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Jan 26, 2018 1:20 pm    Post subject: Reply with quote

Grand Master

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

Well, if you have the power to change your applications easily then you could always connect to both and just alternate who you put the message to. Not quite as dynamic as MQ Clustering but might get you most of the way there and it's not a lot of code.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
nhenshall
PostPosted: Fri Jan 26, 2018 1:33 pm    Post subject: Reply with quote

Novice

Joined: 20 Aug 2007
Posts: 13
Location: Paris, France

Unfortunately, it's a vendor sourced application and we have no access to the source code. However, the vendor is involved with this rollout, so I intend bringing this point up with them on Monday.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Jan 26, 2018 6:04 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

You have a bunch of clients....

Make two channel tables:
CCDT#1 with QM1 as primary, QM2 as secondary, no load balancing, just primary/secondary.
CCDT#2 with QM2 as primary, QM1 as secondary, no load balancing, just primary/secondary.

Give half the bunch CCDT#1, the rest of the bunch CCDT#2.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Load Balancing Client Connections and their Performance.
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.