Mark Lim wrote:
> However, performance is an issue. The evaluator can only get James to
> deliver 5 msgs/sec on 4 processor E450. (vs. 50+ mps for commercial MTAs)
> He believes James is I/O bound.
How big was the average size of the messages?
> Have users had to do any tuning of James once installed?
Yes. It is the number of the spool manager; basically, the more the
better.
James is multi-threaded mail server; meaning: every SMTP connection will
be served by a spool manager thread. Having many TCP connections at once
means that the receiving/sending of the email is done concurently.
> Are there common
> pitfalls to avoid that could affect performance?
Have the mail spool stored in the filesystem. It would be generally
faster than if the spool is on a database. But that could be done if you
are not interested in manually removing the messages that are already in
the spool. Removing the in-the-spool-messages would mean ever-growing
log files, which would eventually fill up your harddisk.
I use a database for the mail store, because it would be easier to
delete some unwanted messages, be it on the mailbox or in the spool. The
only catch is the size of the attachment; I use MySQL and its driver
couldn't deliver more than 1 MB (which might be good -- database wise).
If you wanted to attach some big files (~10MB and up) on your messages,
then database storage wouldn't be your option. (Well, if you have very
large attachments, then email servers wouldn't be your option; the
option would be ftp, IMO.)
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
