Thanks for the initial responses.  For the record, we're looking only at
James' SMTP performance.  However, we may "deliver" messages to James by 
scribbling right to the spool.

The test rig was a 4 processor E450 w/ 1Gb of memory.  James was fed mail from
a "pounder", which simply sends a number of fixed size messages via smtp to a 
target. The tester used OptimizeIt, a profiler which came with Sun's JRE
v.1.2.2, which was the VM used in the test.

A quote from the report:

" Under a variety of different tests, James seemed to be able to suck
down very small SMTP messages (~2k) at a max rate of about 5
messages/sec under a pounding load.  The profiler shows that James
spends a significant amount of time in various I/O routines, possibly
because it is always doing a cycle of "read from socket, write to
spool, read from spool, filter through mailets, write to inbox". "


He ran a couple of tests where he preloaded the spool, picked up the message, 
processed it and then dropped it.  This was an attempt to isolate the
processing stage alone.  BusyWait is a mailet that simply spins for
a number of "milliseconds", taking up processor time to simulate work on the 
message.  

1000 8Kb messages, 8 spoolmanagerthreads
        no BusyWait:            182 s
        BusyWait 100:           184 s
        BusyWait 1000:          278 s

1000 100Kb messages, 8 spoolmanagerthreads
        no BusyWait:            217 s
        BusyWait 100:           213 s
        BusyWait 1000:          325 s
        BusyWait 10000:        2222 s

Sadly, the rates with no Busywait drop non-linearly with spool size.  A spool 
of 500 members is processed in 79 seconds (6.3 msgs/sec) but a spool of
5000 members is processed in 47 minutes (1.8 msgs/sec).  So when
the spool gets behind, it'll be a struggle to catch up.  Spiky behavior is 
very common in mail flow rates as seen from the MTA (start of the business
day, stock alerts, the AnnaKournikova worm...).  While processing the spool,
the CPU usage levels off at 25%, unless BusyWait is being demanding.  

How many spoolmanagerthreads do people typically use?  Any other tuning
tips?


Mark Lim                   Software Yokozuna
Brightmail, Inc.           
415-365-6192               
http://www.brightmail.com  


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to