| Author |
Message
|
| Gideon |
 Posted: Fri Dec 06, 2013 1:59 pm Post subject: SVRCONN and threads |
 |
|
Chevalier
Joined: 18 Aug 2009
Posts: 403
|
I have a client that kicks off 5 to 10 threads
It connects to the following
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.CLNT.SVRCONN) CHLTYPE(SVRCONN)
ALTDATE(2013-12-06) ALTTIME(12.55.0
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) DISCINT(0)
HBINT(300) KAINT(AUTO)
MAXINST(999999999) MAXINSTC(999999999)
MAXMSGL(4194304) MCAUSER(mqm)
MONCHL(QMGR) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(1)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP)
Server is WMQ 7.5
However, my client connects extrmely slowly, too slow for its purpose
Previously it would connect all 5 to 10 threads immediately, now it takes about a minute
How can I resolve the issue
Thanks |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Dec 06, 2013 2:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What changed? Application? O/S? WMQ?
_________________
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 |
|
|
| Gideon |
| Posted: Fri Dec 06, 2013 2:14 pm Post subject: |
|
|
Chevalier
Joined: 18 Aug 2009
Posts: 403
|
| I have no idea. I expected it to come up immediately |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 06, 2013 2:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Maybe the value in sharecnv might have something to do with it? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 06, 2013 4:24 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Gideon wrote: |
| I have no idea. I expected it to come up immediately |
Last alter date is today. What did you alter? When was this definition created?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Dec 06, 2013 5:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What does the client do after establishing the first connection and making the second?
What does the client do after establishing the second connection and making the third?
etc
etc
etc
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Dec 06, 2013 5:36 pm Post subject: Re: SVRCONN and threads |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Gideon wrote: |
| Previously it would connect all 5 to 10 threads immediately, now it takes about a minute |
"Previously" implies something changed between then and now. Find out what changed. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Dec 06, 2013 8:46 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Since the time span is so large you could take an MQ trace and the timestamps will still be meaningful. Even without knowing too much about the internal workings of a channel you should at least be able to see where most of the time is going and which API call you're spending it in. At the very least you should be able to tell whether the delay is on the server or the client. It would be very obvious, for example, by taking a client trace, whether the application itself is being delayed in issuing the MQCONN calls.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 07, 2013 3:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As a "wild" guess, I'd say it may be the difference between shareconv(1) and shareconv(10).
Creating the physical connection takes time.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Dec 08, 2013 8:13 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
As a "wild" guess, I'd say it may be the difference between shareconv(1) and shareconv(10).
Creating the physical connection takes time. |
But a whole minute just to establish 10 connections?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Dec 08, 2013 2:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
As a "wild" guess, I'd say it may be the difference between shareconv(1) and shareconv(10).
Creating the physical connection takes time. |
But a whole minute just to establish 10 connections? |
If they're not cached, 6 seconds to establish a connection may well be within the norm...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| wmbwmq |
| Posted: Mon Dec 09, 2013 10:18 am Post subject: |
|
|
Acolyte
Joined: 18 Jul 2011
Posts: 66
|
I may be wrong but my understanding of SHARECNV is that if it is set to 0 or 1 then client connection speed and the processing speed is actually faster. SHARECNV>1 will result in threads competing for the same socket. I personaly like SHARECNV=1 unless there are known TCP related issues or client uses very high number of threads/connections.
Could be that OP's problme is due to commpletely unrelated load/performance related activity going on in the MQ server or the client server. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Dec 09, 2013 10:38 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Predicting the performance of systems can be very tricky and it's hard to say exactly what the effect will be. However, I suspect that competing for the socket is not the main factor in the performance of SHARECNV > 0 but rather competing for the thread on the server and the additional context switches. In terms of the channels starting, ie. MQCONNX, I would expect SHARECNV>1 to be faster especially if there is any SSL handshaking going on.
Of course your mileage may vary. SHARECNV>0 was added to reduce socket usage and enable full-duplex communications, it was not focussed on increasing performance.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
