You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Mark Lim <li...@brightmail.com> on 2001/06/12 18:38:02 UTC
James performance
Hi,
My company is interested in using James as a mail processor, that is, to
perform transformations on messages before sending them on. The mailet
API seems perfect for this.
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.
I realize I'm not
So questions for community are:
Do any developers know of existing bottlenecks? Any work arounds?
What is the user community experience with performance (numbers
please...)?
Have users had to do any tuning of James once installed? Are there common
pitfalls to avoid that could affect performance?
Thanks all.
Mark Lim Software Yokozuna
Brightmail, Inc.
415-365-6192
http://www.brightmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: James performance
Posted by Harmeet <ha...@kodemuse.com>.
----- Original Message -----
From: "Mark Lim" <li...@brightmail.com>
Are you most concerned about
SMTP thoughput ?
POP3 thoughput ?
Spooling Throughput ?
I find POP3 slow, SMTP ok and Spooling not that important becaue it is a
background activity. Spooling can be made faster by alloting more threads to
it. I have only used the file system repositories.
2 possible problems in POP3 could be.
1. The Mail Messages are read and parsed repeatedly. Thsi is based on
profiling.
Your evaluators IO bottleneck could be coming from this. I think this is
harder to fix but will give good gain.
The workaround is to write a new or iimproved repository or to have disc
with better IO characterstics.
I have thought about writing a new version of file system based Mail
Repository for streaming and faster acess. What do others think about this
idea ?
2. remote IP address lookup in POP3 would be slow. (based on gut feel). I
suspect the first lin POP3Handler can be problematic
a. remoteHost = socket.getInetAddress ().getHostName ();
b. remoteIP = socket.getInetAddress ().getHostAddress ();
The workaround is to tweak with host-IP mapping.
Propose to remove the host lookup (line a), and only log the remote IP
address, unless someone objects.
Harmeet
PS. Brightmail using James would be cool. :-)
----- Original Message -----
From: "Mark Lim" <li...@brightmail.com>
To: <ja...@jakarta.apache.org>
Sent: Tuesday, June 12, 2001 9:38 AM
Subject: James performance
> Hi,
>
> My company is interested in using James as a mail processor, that is, to
> perform transformations on messages before sending them on. The mailet
> API seems perfect for this.
>
> 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.
>
> I realize I'm not
>
> So questions for community are:
>
> Do any developers know of existing bottlenecks? Any work arounds?
>
> What is the user community experience with performance (numbers
> please...)?
>
> Have users had to do any tuning of James once installed? Are there common
> pitfalls to avoid that could affect performance?
>
> Thanks all.
>
> Mark Lim Software Yokozuna
> Brightmail, Inc.
> 415-365-6192
> http://www.brightmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: James performance
Posted by Oki DZ <ok...@bdg.pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org