Hello Enrico,
Basically, you are looking at reading "Event Monitoring" book. To summarize briefly:
after events are allowed (see MQSC book for those attributes I mentioned in my
previous mail), you will be getting the regular mq messages on
SYSTEM.ADMIN.PERFM.EVENT queue. The thread you mentioned would be mostly waiting in
MQGET() on this queue, crack the event messages and respond to getting underflow and
overflow events accordingly (by requesting publishing thread to suspend or resume
publishing). The format of the event messages and examples are all in "Event
Monitoring" book.
Hope this will help,
Pavel
Fichtner Enrico
<enrico.fichtner@ To: [EMAIL PROTECTED]
ELAXY.COM> cc:
Sent by: MQSeries Subject: AW: Re: Performance
observations and questions
List
<[EMAIL PROTECTED]
n.AC.AT>
02/18/2004 02:49
AM
Please respond to
MQSeries List
Pavel,
I have googled the web for a hint on how to use the events in a C++ app - but couldn't
find any. The path is clear so far, use *something* in a separate thread that has
thread-synchro with the thread that does the actual put, when the event occurs simply
let the putting thread run idle (or whatsoever) until the opposite event rises.
However, the *something* is the portion that is not clear, is it a API call that
blocks until the event occurs - or is it a C++ object (wrapped API) that I have to
use? Any hint on this would be extremely helpful.
Thanks, Enrico
-----Ursprüngliche Nachricht-----
Von: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 17. Februar 2004 01:54
An: [EMAIL PROTECTED]
Betreff: Re: Performance observations and questions
Enrico,
Make sure your application does not check the size of the transmission queue "each
time" before putting the message; otherwise, it may affect the performance, especially
if you are interested in highest possible one. An alternative approach (I am not aware
of *the* right one) would be to enable relevant events (see QDPHIEV, QDEPHHI queue
attributes and QM's PERFMEV) and wait for them in a separate thread.. then stop the
publisher. You can use QDPHLOEV to resume publishing in the same manner.
Just my 2c
Pavel
"Gurney, Matthew"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
SFB.COM> cc:
Sent by: MQSeries Subject: Re: Performance observations
and questions
List
<[EMAIL PROTECTED]
n.AC.AT>
02/16/2004 08:51
AM
Please respond to
MQSeries List
Enrico,
IBM provides performance information and tuning recommendations in the support
pacs, this information is not in the manuals. I would recommend you review:
http://www-306.ibm.com/software/integration/support/supportpacs/product.html
MP6J
MP78
In regard to your performance test, I think the reduction in performance when
maximum queue depth was increased was due to you exceeding the QBufferSize for
your queues. By default Q's have 64k of memory assigned to them. If the
total size of all messages upon the queue exceeds 64k then the extra messages
(or perhaps entire q, not sure) are written to disk. Obviously once the disk
gets involved your performance reduces dramatically. You can adjust the
QBufferSize in your qm.ini up to 1MB (you need to delete and recreate the q
after making the qm.ini change).
Matt.
-----Original Message-----
From: Fichtner Enrico [mailto:[EMAIL PROTECTED]
Sent: 16 February 2004 10:06
To: [EMAIL PROTECTED]
Subject: Performance observations and questions
For a upcoming project we needed some figures on MQSeries throughput
to base a design decision on. Throughput is very crucial in this
project. On the last weekend I've conducted some tests in this regard.
Some of the results I would like to discuss here.
Facts:
- the tests where conducted on two Intel machines running W2K with
MQSeries 5.2, however, the project target platform will be
SPARC/Solaris9
- the machines used in this test are a PIV 2.8GH and a 2xPIII 450MH,
both 512MB, one has ultra fast SCSI HD's and one has a pretty fast
IDE-RAID5 (4x160G)
- both machines where connected via 100MB LAN through a switch, which
had only the two machines connected to it
- message size was 200 byte, I used a string made of repeated numbers
of 0 through 9
- queues where not persistent
- DOS based test applications are written in C++, using IBM's C++
interface rather than straight C-API
- the 'putting' application runs in a loop, checking the depth of the
transmission queue (avoiding overflow), if the depth is below a
certain
level it puts the message into the remote queue, every n successful
puts
the time is measured (through windows high frequency counter, very
high
precision) and the average messages per seconds is put on the screen
- the 'getting' application runs in a endless loop, with a blocking
'get'
on the (receiving) local queue, the same average measuring is
implemented
as in the 'putting' app
Results:
- the best throughput was 3200msgs/sec measured with one putting
application
and one getting application at a maximum queue depth of 5000 on both
sides
(remote and transmission queue), CPU's on both sides where far below
100%
- overall throughput went down when several 'putting' applications where
putting to the same queue (of course, taking the sum of all screen
outputs)
Questions:
- what actually limits the throughput? the number of msgs/sec times the
size
in this case results in the best case to 625kB/sec which is far beyond
the
practical throughput of the mentioned LAN
- is it a correct observation that synchronizing several applications
putting
into the same queue causes considerably overhead? if so, can this be
assumed
the same way under SPARC/Solaris9 ?
- when the max queue depth is set to a high number (e.g. 500000),
throughput
goes down to a fraction of the max throughput, MQSeries process
amqzlaa0.exe
'eats' up a lot of CPU power in this case - it seams like that
managing a
lot of messages in a queue causes also relatively large overhead - is
this
correct and how does it translate in generally to SPARC/Solaris9 ?
- what are the recommendations for the setup of MQSeries (installation
itself,
queues, channels, processes ect.) as well as the message processing
(applications) where throughput is the only thing that matters?
Thanks in advance,
Enrico Fichtner
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
