| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Performance questions |
« View previous topic :: View next topic » |
| Author |
Message
|
| steve_baldwin |
 Posted: Wed Oct 17, 2001 9:38 pm Post subject: |
 |
|
Novice
Joined: 30 Sep 2001
Posts: 11
Location: Melbourne, Australia
|
Hi there,
I have recently been doing some benchmarking (not terribly scientific) comparing MQ performance on different platforms. The results have surprised me very much, and I'd be interested in feedback.
Basically, I wrote a small C program that took as command line arguments the message size, and the number of messages (plus QMgr and queue). It then filled a buffer to the requested size with random chars, and put the requested number of messages on the queue. It then read them all back until the queue was exhausted. The program was compiled, unchanged on each of the 3 platforms. Here's the results ...
The numbers are message throughput (get or put) in messages per second. The size column is the size of the message in bytes.
| Code: |
Machine A
Size Get Put
100 3909 2888
1000 3855 2751
10000 1884 1728
Machine B
100 1183 218
1000 1117 204
10000 241 35
Machine C
100 1540 1262
1000 1474 1311
10000 467 342
|
Here's the surprising bit. Machine A is a PC with a PIII 500MHz running Linux. Machine B is a 4 CPU HP k580, and Machine C is a single CPU Sun 250.
I can't believe the figures, but I've re-run them many times, with the same result. What is so horribly out of 'tune' on the HP K class machine that makes it nearly 50 times slower than a PC running Linux ????
[ This Message was edited by: steve_baldwin on 2001-10-17 22:40 ] |
|
| Back to top |
|
 |
| jhalstead |
| Posted: Thu Oct 18, 2001 5:04 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Very interesting!
Are all qmgrs on the same version of MQSeries?
Are you specifying a persistence attribute in the population of the MQMD header? If you are choosing to inherit the persistence of the target queue then maybe the queue persistence definitions are different on the different gmgrs?
|
|
| Back to top |
|
|
| steve_baldwin |
| Posted: Thu Oct 18, 2001 1:22 pm Post subject: |
|
|
Novice
Joined: 30 Sep 2001
Posts: 11
Location: Melbourne, Australia
|
In each case the version of MQ is 5.1, with latest patches. The queue is defined with no persistence, and the MD is also defined with no persistence.
Maybe this is something IBM dont want us to know  otherwise we'd run our QMgrs on PC's (running Linux of course), and save a fortune on licencing. |
|
| Back to top |
|
|
| kolban |
| Posted: Thu Oct 18, 2001 1:43 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
How were the machines bound? CPU bound or I/O bound? Since you were only running one instance of the program, you took no advantage of the multi-processor capabilities of the HP machine.
What were the relative CPU capacities of the processors of the machine? How much RAM was available on each machine? Did all the queues initially start empty? Did paging occur and, if so, is paging on the same device as the queue files? |
|
| Back to top |
|
|
| steve_baldwin |
| Posted: Thu Oct 18, 2001 2:24 pm Post subject: |
|
|
Novice
Joined: 30 Sep 2001
Posts: 11
Location: Melbourne, Australia
|
The HP machine was certainly not CPU bound. It has a very fast disk subsystem, so, although I don't know for sure, I don't think it was IO bound either. Not sure what that leaves. As far as memory goes, machine A (Linux) has 256 MB, machine B (HP) has 3 GB, and machine C (Sun) has 512 MB. The CPU's on the HP are (I think) 400 MHz RISC. As far as utilising multiple CPU's, I would have thought that at the very least my program, and the MQ queue manager could run concurrently on different CPU's - giving it the edge over the other two single CPU boxes.
I also tried the test program on a HP D360 machine which also has 4 CPU's that are slightly slower than the K class machine. It has 1.5 GB memory, and a similar disk subsystem to the K class. It's results were around the same, or slightly slower than the K class (machine B).
One thing I find confusing is that we run Oracle (8.1.7) on each machine, and the HP K class is far and away the fastest for Oracle. |
|
| Back to top |
|
|
| kolban |
| Posted: Thu Oct 18, 2001 3:58 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
There should actually be very little natural parallelism going on. Either the application is building messages or it is waiting on MQ to put/get a message. While waiting, MQ is has the CPU .... so you are flip/flopping between potentially only two processes which are in lock step with each other.
Are you running HPUX 11? I believe that is a 64 bit O/S? I think current MQ for HPUX is only 32 bit (won't swear to it ...)
While running on HPUX, try using vmstat and see how much CPU is being used. If you have 4 CPUs, I suspect that you will see 25% CPU being consumed which I will read as 100% of 1 CPU. |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Oct 18, 2001 5:03 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I agree with Neil... I have done similar tests on multiprocessor machines, and if I'm only running a single application talking to the queue manager, the other CPUs basically sit idle and the queue manager and my application swap in and out depending on whether my process is waiting for a reply from the queue manager, or the queue manager is waiting on I/O... You could probably strip out the other 3 CPUs from your HP-UX and your throughput shouldn't diminish an appreciable amount...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Tibor |
| Posted: Thu Oct 18, 2001 10:29 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Quote: |
On 2001-10-18 14:22, steve_baldwin wrote:
In each case the version of MQ is 5.1, with latest patches. The queue is defined with no persistence, and the MD is also defined with no persistence.
|
If I remember right, first official MQ version on Linux is v5.2. Of course, there was version 5.1beta.
But this is an interesting test for me, too. I would try this program on AIX and Tru64, if you send me C source. Then post the performence results this forum.
|
|
| Back to top |
|
|
| steve_baldwin |
| Posted: Fri Oct 19, 2001 2:52 am Post subject: |
|
|
Novice
Joined: 30 Sep 2001
Posts: 11
Location: Melbourne, Australia
|
You're quite correct about Linux.
For those that are interested, here's the code (basic as it is) ...
| Code: |
/*******************************************************************************
* Module : ??Prog??
* Application : Hansen Universal Billing (HUB)
* Author : Steve Baldwin
* Spec X-Ref :
* Purpose : Skeleton C program
*
* Revision History (see PVCS history for who, and when) :
*
* Version Reason/Changes
* ------- -------------------------------------------------------------
* 1.0 Initial Version
*
*******************************************************************************/
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <cmqc.h>
#include <sys/time.h>
#define TRUE (1 == 1)
#define FALSE (1 == 0)
/*
* Global Variables
*/
char *ModuleName = "",
*QMName = "",
*QName = NULL,
*MsgID = "" ;
unsigned char *MText = NULL ;
int nMsg = 1,
Random = FALSE,
MsgSize = 0 ;
/*
* Function Prototypes
*/
int Initialise (int argc, char **argv) ;
void Usage (void) ;
int
Initialise (int argc, char **argv)
{
int status = 0,
argerr = 0,
i ;
/*
* Process command line arguments
*/
opterr = 0 ;
while ((status == 0) && ((i = getopt (argc, argv, "Q:q:m:t:n:rs:")) != EOF)) {
switch (i) {
case 'Q' :
QMName = optarg ;
break ;
case 'q' :
QName = optarg ;
break ;
case 'm' :
MsgID = optarg ;
break ;
case 't' :
MText = (unsigned char *)optarg ;
break ;
case 'n' :
nMsg = atoi (optarg) ;
break ;
case 'r' :
Random = TRUE ;
break ;
case 's' :
MsgSize = atoi (optarg) ;
break ;
case '?' :
++argerr ;
break ;
}
}
if (argerr > 0) {
status = 1 ;
Usage () ;
}
return (status) ;
}
void
Usage (void)
{
fprintf (stderr, "usage : %s [options]n", ModuleName) ;
fprintf (stderr, "where [options] can be :n") ;
fprintf (stderr, "t-Q Name Attach to Queue Manager {Name}n") ;
fprintf (stderr, "t-q Name Put messages to queue {Name}n") ;
fprintf (stderr, "t-m MsgID Stamp messages with ID {MsgID}n") ;
fprintf (stderr, "t-t xxxxx Set text of message to {xxxxx}n") ;
fprintf (stderr, "t-n Count Put {Count} copies of the message of the queuen") ;
fprintf (stderr, "t-r Fill the message with random charactersn") ;
fprintf (stderr, "t-s bytes Create message of {bytes} in sizen") ;
}
int
main (int argc, char **argv)
{
int status = 0 ;
MQHCONN hQM ;
MQHOBJ hQ ;
MQOD od = { MQOD_DEFAULT } ;
MQPMO pmo = { MQPMO_DEFAULT } ;
MQMD md = { MQMD_DEFAULT },
md_dflt = { MQMD_DEFAULT } ;
MQGMO gmo = { MQGMO_DEFAULT } ;
unsigned rnd_seed ;
char Random_state [256] ; /* state information for the random() function */
int i, j ;
long oo,
cc, rc,
sz ;
struct timeval t1, t2 ;
double t_rate ;
ModuleName = argv [0] ;
if ((status = Initialise (argc, argv)) != 0)
goto main_exit ;
/*
* Initialise random number generator
*/
rnd_seed = (unsigned)time (NULL) ;
(void)initstate (rnd_seed, Random_state, sizeof (Random_state)) ;
if (MsgSize > 0) {
if ((MText = (unsigned char *)malloc (MsgSize)) == NULL) {
fprintf (stderr, "failed to malloc %d bytes of memory (%s)n", MsgSize, strerror (errno)) ;
exit (1) ;
}
}
if (Random) {
for (j = 0 ; j < MsgSize ; j++) {
MText [j] = (unsigned char)random () ;
}
}
else
MsgSize = strlen ((char *)MText) ;
MQCONN (QMName, &hQM, &cc, &rc) ;
if (cc == MQCC_OK) {
strncpy (od.ObjectName, QName, (size_t)MQ_Q_NAME_LENGTH) ;
oo = MQOO_INPUT_SHARED + MQOO_OUTPUT ;
MQOPEN (hQM, &od, oo, &hQ, &cc, &rc) ;
if (cc == MQCC_OK) {
fprintf (stdout, "Starting put of %d messagesn", nMsg) ;
memset ((char *)md.MsgId, ' ', sizeof (md.MsgId)) ;
memcpy ((char *)md.MsgId, MsgID, strlen (MsgID)) ;
md.Expiry = MQEI_UNLIMITED ;
md.Report = MQRO_NONE ;
md.MsgType = MQMT_DATAGRAM ;
md.Priority = 1 ;
md.Persistence = MQPER_PERSISTENCE_AS_Q_DEF ;
(void)gettimeofday (&t1, NULL) ;
for (i = 0 ; i < nMsg ; ++i) {
MQPUT (hQM, hQ, &md, &pmo, MsgSize, MText, &cc, &rc) ;
if (cc != MQCC_OK)
break ;
}
(void)gettimeofday (&t2, NULL) ;
t2.tv_sec -= t1.tv_sec ;
if (t1.tv_usec > t2.tv_usec) {
t2.tv_sec-- ;
t2.tv_usec += 1000000 ;
}
t2.tv_usec -= t1.tv_usec ;
t_rate = (double)i / (double)(t2.tv_sec + (t2.tv_usec / 1000000.0)) ;
fprintf (stdout, "Completed %d puts in %d.%06d secs : throughput = %8.1f msg/secn",
i, t2.tv_sec, t2.tv_usec, t_rate) ;
fprintf (stdout, "Starting getsn") ;
(void)gettimeofday (&t1, NULL) ;
for (i = 0 ; ; i++) {
sz = MsgSize ;
memcpy (&md, &md_dflt, sizeof (md)) ;
MQGET (hQM, hQ, &md, &gmo, MsgSize, MText, &sz, &cc, &rc) ;
if (cc != MQCC_OK) {
break ;
}
}
(void)gettimeofday (&t2, NULL) ;
t2.tv_sec -= t1.tv_sec ;
if (t1.tv_usec > t2.tv_usec) {
t2.tv_sec-- ;
t2.tv_usec += 1000000 ;
}
t2.tv_usec -= t1.tv_usec ;
t_rate = (double)i / (double)(t2.tv_sec + (t2.tv_usec / 1000000.0)) ;
fprintf (stdout, "Completed %d gets in %d.%06d secs : throughput = %8.1f msg/secn",
i, t2.tv_sec, t2.tv_usec, t_rate) ;
MQCLOSE (hQM, &hQ, MQCO_NONE, &cc, &rc) ;
}
else {
fprintf (stderr, "MQOPEN failed : rc=%dn", rc) ;
status = 1 ;
}
MQDISC (&hQM, &cc, &rc) ;
}
else {
fprintf (stderr, "MQCONN failed : rc=%dn", rc) ;
status = 1 ;
}
main_exit :
return (status) ;
}
|
|
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Oct 19, 2001 5:27 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
perftest -Q TEST -q T1 -r -s Size -n 5000
AIX (1 CPU), MQ v5.1.0.7:
Size Get Put
100 3365 2876
1000 3365 613
10000 2469 65
AIX (2 CPU), MQ v5.2.0.1:
Size Get Put <--- First test after DEFINE QLOCAL
100 3365 2876
1000 3365 613
10000 2469 65
Size Get Put <--- Second,...
100 5426 4972
1000 5262 4672
10000 3297 2832
First impressions after running your test proggy:
There is an important difference between v5.1 and v5.2. With v5.1 I didn't discover significant variation in values. v5.2 is working other way - maybe re-using the big queue file?
|
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Oct 19, 2001 5:54 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
(continued)
Tru64 4.0F, MQ v5.1.0.0 (overloaded by Oracle):
Size Get Put
100 609 567
1000 598 549
10000 492 293
|
|
| Back to top |
|
|
| kolban |
| Posted: Fri Oct 19, 2001 6:16 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
On a Pentium IV 1.4GHz on Windows 2000 FP 2 with 512Mbytes ram:
Size Get Put
100 14705 9784
1000 14285 8460
10000 7032 4500
MQ Series V5.2.1 |
|
| Back to top |
|
|
| steve_baldwin |
| Posted: Fri Oct 19, 2001 1:29 pm Post subject: |
|
|
Novice
Joined: 30 Sep 2001
Posts: 11
Location: Melbourne, Australia
|
| Apart from moving from MQ 5.1 to 5.2, what conclusions can we draw from this ? Is anyone else out there running MQ on an HP K class ? Can anyone suggest any changes we could look at making to lift the MQ performance on this otherwise "grunty" machine. I find it hard to understand why our performance "champion" (so far) is a PC with a relatively modest CPU (2 GHz are freely available) costing maybe a couple of thousand dollars. |
|
| Back to top |
|
|
| kolban |
| Posted: Fri Oct 19, 2001 1:52 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
I couldn't even find details of a K-Class machine at HP's website other than to say it was an entry level box. The L-Class seems to talk about 360Mhz processors so K may be even slower (Mhz).
I would suggest that you do a raw performance comparison. Write an obviously CPU intensive application (add 1000000 floating point numbers ...) and run on each platform. See what sorts of base benchmarks you see.
What was the vmstat log for the runs of the program on HP? |
|
| Back to top |
|
|
| steve_baldwin |
| Posted: Fri Oct 19, 2001 3:23 pm Post subject: |
|
|
Novice
Joined: 30 Sep 2001
Posts: 11
Location: Melbourne, Australia
|
I think our K class is a superseeded version of what is now a L2000. It has 440 MHz CPUs. It looks like it must be purely related to clock speed. Here's my little FP bmark program ...
| Code: |
#include <stdio.h>
int
main (int argc, char **argv)
{
double d_tot = 0,
d_incr = 0.000001 ;
long i ;
for (i = 0 ; i < 100000000 ; i++) {
d_tot += ((d_incr * (double)i) / (7.0 / ((double)i + .0000001))) ;
}
printf ("total is now %fn", d_tot) ;
}
|
Heres the results
Machine A (Linux) 14.8 sec
Machine B (HP) 34.9 sec compiled with gcc
Machine B (HP) 14.8 sec compiled with HP cc
Machine C (Sun) 25.3 sec
Not sure whether this is conclusive, but I'm sure surprised at the difference in performance when using the different compilers. gcc is version 3.01. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
