JAMES BY THE NUMBERS

Testing James for Scalability.

A James user created and ran a test scenario to test James' SMTP throughput. (this first appeared on the user mailing list http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-user@jakarta.apache.org&msgNo=7689)

Test scenario:

  • Send ‘n’ mails/min to server1. Server1 processes these mails and sends them to server2. Server2 ghosts the mails.
  • Started by sending 800 mails/min to server1. We were constantly following up with the spool size of James.
  • We kept increasing the mails/min till we saw a rate when james couldn’t handle 100% of the mails.
  • Varying message size, but not exceeding 10kb
  • Server1 had 3 repository hops, meaning message arrived and went into one spool, during processing email moved to second spool, and outgoing delivery put email in 3rd spool.
  • Client sending the emails was on another server.

Platform:

  • Servers were 2.4 Ghz Pentium 4 with 1 GB of memory.
  • Redhat 9.0
  • Network between servers: 100 Mbit/s
  • James database repository. By making james and james’s database repository use the same server leads to contention of CPU time and james doesn’t perform to its fullest. Therefore the database repository (mySQL) was installed on a different server.
  • mySQL 4.0.13 and JDBC connector 3.0.9.
  • JDK 1.4.2 was used with the –server option and we also set the JVM heap to be 384 MB.

Tuning:

  • By using trial and error and some logic we came up with the optimal number of spool threads to be 12 and the outgoing threads to be 20 for server1.
  • Server2 used 100 spool threads.
  • Maxcache was set to be 125.
  • Max connection for the database was set to 20.

Results:

  • James was able to process (receiver/process/send) all of the 800 mails/min.
  • As we increased the rate, James comfortably processed around 2600 mails/min with a CPU usage of 70% for James and the CPU usage of 30% for mySQL
  • When we reached 2800 mails/min, the spool started increasing in size and the number of mails processed per min started decreasing. The decrease was exponential with the increase in the number of messages/min. When we sent 4000 mails/min, james processed 400 mails/min.

Conclusion:

  • James with our current configuration can handle 2600 mails/minute which is pretty neat.
  • No labels