Author |
Message
|
vincent |
Posted: Thu May 11, 2006 7:49 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
Yes. It is done on 5.3 CSD 12 on Solaris box. This is for both the server and client
But in client, we use 5.2 Windows version. Is it ok? or Windows also should have a same 5.3 with latest CSD? |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu May 11, 2006 7:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There are huge performance increases between 5.2 and 5.3. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
vincent |
Posted: Thu May 11, 2006 7:59 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
I forgotten, Windows use JMS client to talk to MQ Server on Solaris. So Windows client is not required, right |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu May 11, 2006 8:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There are big performance gains in the JMS implementation in v5.3.
But please be clear again. Your C++ testing programs are running locally on the Solaris machine - so they are using the 5.3 CSD 12 client?
And, again, you are not seeing any CPU utilization issues when running your programs, and you are not seeing any disk utilization issues when running your programs, and you are not seeing any memory utilization issues when running your programs? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
vincent |
Posted: Thu May 11, 2006 9:49 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
jeff,
The testing c++ application which is running on solaris has both the client and server and its CSD is 12.
All other resources are normal when i run more than one reader client |
|
Back to top |
|
 |
vincent |
Posted: Thu May 11, 2006 9:54 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
Would modifying kernel parameters(shared memory, semaphors and messages ) help to improve the throghput phenominanly?
-vincent. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu May 11, 2006 5:09 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
JMS is a pig. Its gonna be slower. An old version of the JMS client is gonna be even slower. And if you do selective gets incorrectly with JMS, you are really gonna crawl. Do a search on JMS + Selective + Gets with my name as the author. You'll be interested in that post. And upgrade that client ! _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
vincent |
Posted: Mon May 15, 2006 9:44 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
No luck. Both the JMS client and Solaris Client written in C++ does not distribute the workload when we increase the client instances. The Transaction per second is same in both the situation,Single client or multiple client. Do not understand why it is not sharing the workload or retrieving messages?
-vincent |
|
Back to top |
|
 |
vincent |
Posted: Wed May 17, 2006 5:54 pm Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
Hi everyone,
I solved the reader problem by telling the folks to add MQOO_INPUT_SHARED while opening a Q for reading.
I have added more clients to add the messgages and able to go up to 1500 transaction per second. And the same way i added more clientes to retrieve the messages from the Q, which also 1500 transaction per second .
But the real problem is not solved.
When i ran both Add / Retrievel together. the rate went down to 80 transaction per second. I could not understand. Let me know if the codes needs to have any specific attributes like above.
-vincent |
|
Back to top |
|
 |
Nigelg |
Posted: Thu May 18, 2006 12:46 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
For best performance you should be putting and getting msgs in syncpoint, even if each UoW contains only a single MQI call. The reason is that the queue lock is held for the duration of the MQI call, but in syncpoint the log force, the potentially slowest part of the operation, is not done while the lock is held, enabling more concurrency in access to the queue. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
Nigelg |
Posted: Thu May 18, 2006 12:47 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
For best performance you should be putting and getting msgs in syncpoint, even if each UoW contains only a single MQI call. The reason is that the queue lock is held for the duration of the MQI call, but in syncpoint the log force, the potentially slowest part of the operation, is not done while the lock is held, enabling more concurrency in access to the queue. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
vincent |
Posted: Thu May 18, 2006 7:34 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006 Posts: 81
|
Nigelg, The code is using Syncpoint. |
|
Back to top |
|
 |
|