| Author |
Message
|
| knwoolley |
 Posted: Thu Apr 26, 2007 2:58 am Post subject: Client connect to queue manager very slow |
 |
|
Newbie
Joined: 01 Mar 2007
Posts: 6
|
I have a VC++ application on XP using MQ client v6 to connect to a queue manager running on AIX.
I have run this application on various PCs and found strikingly different results in the time it takes for the ImqQueueManager connect() method to return.
On some PCs the response is instant (up to 31ms). On others it takes around 5 seconds (usually just over 5 seconds).
I have 2 PCs that I have investigated, one slow and one fast. The PCs appear to be identically configured and when I switch network cables between the machines the results are the same (the fast machine remains fast and the slow one remains slow), so I have to conclude that the network is not responsible.
Thanks for any help you can offer.....
Kevin |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Apr 26, 2007 3:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Are the results consistent over an extended period? Is the slow machine slow today like it was yesterday and will be tomorrow, or is it slow today but better yesterday?
And it's the same queue manager in each test, under a similar load in each instance?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| knwoolley |
| Posted: Thu Apr 26, 2007 4:21 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2007
Posts: 6
|
Yes, the results are consistent over an extended period. (The machine where I developed the application was slow and I was amazed when I first ran the application on a "fast" machine!)
I can start the application at the same time on both machines with no change in the result.
They are connecting to the same queue manager, which is under similar load. The 2 PCs are under comparable load to each other. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2007 4:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If that's the case then my next guess is network. Swapping the cables over will not change the IP address of the machine (unless you reboot) and hence their route to the AIX box. I'd try a tracert from each machine to see if they're following the same route or if the "slow" machine is bouncing round inside the network a bit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| knwoolley |
| Posted: Thu Apr 26, 2007 5:14 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2007
Posts: 6
|
The tracert output is identical on each machine (1 hop, <1ms).
The "slow" machine doesn't appear to be any slower than the "fast" one when doing other things over the network.....which makes this a bit of a mystery. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 26, 2007 5:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What happens when you run the program on the fast machine, using the user on the slow machine?
or is it the same user name?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| knwoolley |
| Posted: Thu Apr 26, 2007 5:56 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2007
Posts: 6
|
I am logged into each machine as the same user (I log onto a domain).
However, the channel I'm using has its MCAUSER set as well. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Apr 27, 2007 7:09 am Post subject: |
|
|
Guest
|
I'm guessing that you are using the client channel table. Yes?
I've had similar results with the client channel table. With a dozen or so CLNTCONN channels, servers geographically dispersed, I've experienced 10 seconds delay before a server qmgr responds or the connect fails completely. I don't believe it's a language-specific issue, as I've used the supplied utilities like amqsput and amqsreq with these results.
Without doing any real, pseudo-scientific experimentation, I could speculate that the client tries to make contact with the server, one server at a time, for all qualified servers in the table, until one answers up. I'd speculate that the client tries, then waits, before assuming that the server is not going to respond; then tries the next server in the table. Repeat for each CLNTCONN in the table. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Apr 27, 2007 7:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That would assume different client tables on the slow machine than the fast machine.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| knwoolley |
| Posted: Mon Apr 30, 2007 12:24 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2007
Posts: 6
|
Thanks to all who have spent time thinking about this issue and posting replies so far.
I'm afraid I don't know what client channel tables are, so I don't think we're using them.
The application attempts to connect to the queue manager listener by setting the connection name on the ImqChannel object in the format <IP address>(<port>) where <IP address> is the IP address of the machine on which the queue manager is running and <port> is the port which its listener is using. |
|
| Back to top |
|
|
|
|
