зеркало из https://github.com/mozilla/gecko-dev.git
77 строки
3.5 KiB
Plaintext
77 строки
3.5 KiB
Plaintext
|
|
MSTONE 4.2
|
|
|
|
Mstone is a mail server performance testing tool designed to simulate
|
|
the different types and volume of mail traffic a mail server would
|
|
experience during a peak activity period. Mstone was formerly known
|
|
as Mailstone.
|
|
|
|
A quick installation guide is available in INSTALL.
|
|
|
|
The full Mailstone 4.15 user manual is available at
|
|
http://developer.iplanet.com/docs/manuals/messaging.html
|
|
|
|
|
|
Testing strategy
|
|
----------------
|
|
|
|
Mstone is capable of opening SMTP, POP3, IMAP4, and other protocol
|
|
connections to mail servers. The number and type of connections made
|
|
to the mail server is based on a weighted command list which provides
|
|
the ability to test mail server implementation requirements.
|
|
|
|
A series of perl script allow you to setup client machines, run tests,
|
|
and then cleanup client machine files. Each client machine has a copy
|
|
of the mailclient program and SMTP message files. When the test is
|
|
run, the mailclient is started with the proper command line and work load.
|
|
|
|
After experimenting with mstone loads, you will notice that there
|
|
are a few factors that can distort server the byte and message
|
|
throughput. You will find that the server byte throughput is related
|
|
to the average SMTP message (file) size. Also, server throughput, in
|
|
bytes and messages, is affected by larger than normal POP3/IMAP4
|
|
mailboxes. So it is important to approach the mstone command
|
|
configuration with data collected from existing mail server
|
|
implementations, for example, a customer might say "during our peak
|
|
activity in the morning, we handle up to two thousand employees
|
|
sending an average of 5 messages of 20K average size and receiving 25
|
|
messages of same size". With input like this, you can begin tuning
|
|
mstone to generate relevant data.
|
|
|
|
There are two important things to consider when reviewing the results of
|
|
mstone performance analysis: Was the test run on target for
|
|
simulating the type and volume of mail traffic; and did the server, both
|
|
software and machine, handle the load within an acceptable margin?
|
|
|
|
With this information, it can be determined: whether enough SMTP
|
|
connections were made to the server during the run, and how many
|
|
messages were downloaded over how many POP3/IMAP4 connections. If the
|
|
number of SMTP connections is not in the acceptable range, then
|
|
consider adding more client processes/machines or checking the server
|
|
performance during the run. The message/connection ratio for
|
|
POP3/IMAP4 should be checked for soundness, and adjustments should be
|
|
made to the mailboxes before running the next test.
|
|
|
|
Monitoring the server performance during test runs is crucial in
|
|
understanding the results. If the number of client connections is not
|
|
being achieved and the server cpu usage and process run queue is not
|
|
settling down after the initial spike, then modifications to the server
|
|
architecture could be in order.
|
|
|
|
The analysis of mstone results is an iterative process of client
|
|
(mstone client) and server tuning. The bottom line is to determine
|
|
whether the messaging solution can handle the type of load expected in
|
|
an acceptable manner.
|
|
|
|
|
|
Server Log Tuning
|
|
-----------------
|
|
The Messaging and Directory server ship with access logging enabled by
|
|
default. This gives the most information about what is going on in
|
|
the system, but can reduce performance. You should test the way the
|
|
system will be run.
|
|
|
|
Noticeable performance increases are often obtained by disabling access
|
|
logging on the directory server and by reducing the logging level of
|
|
the messaging servers from "Notice" to "Warning".
|