Thanks for the responses. More on the configuration.
With the Sun Blade we would max it out. 2 CPU's, 2 gig of memory. This
server is located in our DMZ and is used
to position data from our MVS QM through this DMZ QM and eventually
straight through to a queue manager located
outside of our company. So all of the message processing is done on the
3rd QM located at the other companies
location. This server in the DMZ is more or less a router to separate our
MVS system from the outside world.
Wesley Shaw
OJRP 10th Floor
Work: 804 771 3589 (736-3589)
Pager: 888 436 2805 Mobile 804 512 5260
Michael F
Murphy/AZ/US/MQ To: [EMAIL PROTECTED]
Solutions cc:
<mmurphy@MQSOLU Subject: Re: Sizing a Sun Server for MQ
TIONS.COM>
Sent by:
MQSeries List
<MQSERIES@AKH-W
IEN.AC.AT>
11/26/02 12:00
AM
Please respond
to MQSeries
List
A "Sun Blade" is a workstation so that is the first concern. These also
come in various sizes, number of CPU, memory and so forth so this is really
not enough information. You have to consider all the resources and
application design to size your server. You 300,000 per hour is really
nothing to an enterprise server, but may be too much for your workstation.
Here are some observations about your post and my comments:
1) You are using a SAN. This is fast so I/O should be pretty good. A SAN
should buffer the data and write later so your app and queue manager can go
about their business.
2) Non-persistent messages are written to memory, not to a file. However,
there is a limit to this buffer and then it writes to disk. If your
receiving app gets the message at the same time it is put, it actually
never even hits the queue, it is just a hand-off. The troubling part is
you mention larger messages going in the same direction as the reply. The
larger messages can fill up the queue buffer faster and cause disk I/O
sooner.
3) Is there any distributed queuing? It almost sounds like you are
connecting to another queue manger but that is not mentioned. If this is
so, you also have to consider network bottlenecks that can cause queue
build-up. Also if the large message go across the same channel as your
replies, you will slow down the reply messages. Consider a separate
channel for large messages and replies so a large message does not hold up
a small reply. Of course you don't mention size. If large to you is 500
bytes, don't worry about this.
4) How much of the machine will the applications use up? Memory, CPU
time, disk space, disk I/O? If you push the machine too far you can cause
it to crawl. Be careful about this.
Overall, the machine can probably handle it. The question is how well will
it perform. I mean I could probably do this on my laptop, but it will be
running pretty slowly. I do know of NT machines with two 400 mhz
processors handling such a workload and they do fine. But they could do
better. It depends on how important the application is to you.
Mike Murphy
Sr. Middleware Consultant
MQ Solutions, LLC
http://www.mqsolutions.com
Wesley Shaw <[EMAIL PROTECTED]> wrote:
Date 11/25/2002 11:45:30 AM
Recieved:
To: [EMAIL PROTECTED]
cc:
Bcc
Subject: Sizing a Sun Server for
MQ
We have an application which at times will be processing lots of messages
in a short period of
time. Somewhere around 100,000 request per hour, followed by the same
reply message amounts.
Then another 100,000 of larger messages flowing in the same direction of
the reply.
So a total of 300,000 per hour. None are persistent.
In sizing a server, could a Sun Blade keep up with this volume ?
Especially with the disk being
located on a Storage area network.
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
