You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ji...@apache.org on 2004/04/14 07:15:43 UTC
[jira] Updated: (JAMES-46) SMTP server against DB repository doesn't scale with message size
The following issue has been updated:
Updater: Noel J. Bergman (mailto:noel@devtech.com)
Date: Tue, 13 Apr 2004 10:14 PM
Changes:
assignee changed from James Developers Mailing List
description changed from I was kind of surprised that this one didn't make it into the bug system yet,
so I'm submitting it. Comments lifted off the james-user mailing list.
The original submission:
> System:
> Dedicated machine.
> Win2000 Professional SP2
> 500Mhz
> 256MB RAM
> James 2.0a3
> Connecting to MSSQL 2000 SP2 for message storage and users/lists, with
> the latest SQL JDBC driver from Microsoft.
>
> Config:
> No limit on message size
> Increased SMTP timeout to 24 minutes
>
> Problem:
>
> 10MB messages take about 12 minutes to process through the system with
100%
> CPU, with no other activity/messages to process, which is ok. But, I
> am having a problem with messages over 15MB.
>
> At the start of the processing of the message the James goes to 100%
> CPU
for
> 10 secs, 30% for 15 secs then 100% again for 100 secs. Then drops back
> to idle. The message then stays in the spool directory and does not
> get processed. Restarting James still has no affect.
>
> I realise that sending messages of this size in general everyday use
> is
not
> one of the best ways to work, but every now and again there is a need
> to send a large file by mail.
>
> What is the largest message that anyone has processed through James?
> Has anyone else come across this, and if so is there something I can
> to
can
> do?
>
> Thank you in advance
>
> James Gooding
and Serge's response:
>I've seen similar performance problems, and it seems to be combination of
>JDBC and JavaMail. I tried to use some performance analysis tools to spot
>what the slow down was, and never got anywhere. I also had weird behavior
>running inside Avalon/James (compared to running a stand-alone test) where
>inside Avalon was taking 5 times as long.
>
>Anyway, yes that is unfortunately not surprising, and nobody has been able to
>crack this performance nut. The file repository is much faster if you do
>need to support large messages like that.
>
>Serge Knystautas to I was kind of surprised that this one didn't make it into the bug system yet,
so I'm submitting it. Comments lifted off the james-user mailing list.
The original submission:
> System:
> Dedicated machine.
> Win2000 Professional SP2
> 500Mhz
> 256MB RAM
> James 2.0a3
> Connecting to MSSQL 2000 SP2 for message storage and users/lists, with
> the latest SQL JDBC driver from Microsoft.
>
> Config:
> No limit on message size
> Increased SMTP timeout to 24 minutes
>
> Problem:
>
> 10MB messages take about 12 minutes to process through the system with
100%
> CPU, with no other activity/messages to process, which is ok. But, I
> am having a problem with messages over 15MB.
>
> At the start of the processing of the message the James goes to 100%
> CPU
for
> 10 secs, 30% for 15 secs then 100% again for 100 secs. Then drops back
> to idle. The message then stays in the spool directory and does not
> get processed. Restarting James still has no affect.
>
> I realise that sending messages of this size in general everyday use
> is
not
> one of the best ways to work, but every now and again there is a need
> to send a large file by mail.
>
> What is the largest message that anyone has processed through James?
> Has anyone else come across this, and if so is there something I can
> to
can
> do?
>
> Thank you in advance
>
> James Gooding
and Serge's response:
>I've seen similar performance problems, and it seems to be combination of
>JDBC and JavaMail. I tried to use some performance analysis tools to spot
>what the slow down was, and never got anywhere. I also had weird behavior
>running inside Avalon/James (compared to running a stand-alone test) where
>inside Avalon was taking 5 times as long.
>
>Anyway, yes that is unfortunately not surprising, and nobody has been able to
>crack this performance nut. The file repository is much faster if you do
>need to support large messages like that.
>
>Serge Knystautas
environment changed from Operating System: Other
Platform: Other to Operating System: Other
Platform: Other
priority changed to Major
Version changed to 2.1.3
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/JAMES-46?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JAMES-46
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JAMES-46
Summary: SMTP server against DB repository doesn't scale with message size
Type: Bug
Status: Unassigned
Priority: Major
Project: James
Components:
SMTPServer
Versions:
2.1.3
2.0a3
Assignee:
Reporter: Peter M. Goldstein
Created: Sun, 28 Jul 2002 9:04 PM
Updated: Tue, 13 Apr 2004 10:14 PM
Environment: Operating System: Other
Platform: Other
Description:
I was kind of surprised that this one didn't make it into the bug system yet,
so I'm submitting it. Comments lifted off the james-user mailing list.
The original submission:
> System:
> Dedicated machine.
> Win2000 Professional SP2
> 500Mhz
> 256MB RAM
> James 2.0a3
> Connecting to MSSQL 2000 SP2 for message storage and users/lists, with
> the latest SQL JDBC driver from Microsoft.
>
> Config:
> No limit on message size
> Increased SMTP timeout to 24 minutes
>
> Problem:
>
> 10MB messages take about 12 minutes to process through the system with
100%
> CPU, with no other activity/messages to process, which is ok. But, I
> am having a problem with messages over 15MB.
>
> At the start of the processing of the message the James goes to 100%
> CPU
for
> 10 secs, 30% for 15 secs then 100% again for 100 secs. Then drops back
> to idle. The message then stays in the spool directory and does not
> get processed. Restarting James still has no affect.
>
> I realise that sending messages of this size in general everyday use
> is
not
> one of the best ways to work, but every now and again there is a need
> to send a large file by mail.
>
> What is the largest message that anyone has processed through James?
> Has anyone else come across this, and if so is there something I can
> to
can
> do?
>
> Thank you in advance
>
> James Gooding
and Serge's response:
>I've seen similar performance problems, and it seems to be combination of
>JDBC and JavaMail. I tried to use some performance analysis tools to spot
>what the slow down was, and never got anywhere. I also had weird behavior
>running inside Avalon/James (compared to running a stand-alone test) where
>inside Avalon was taking 5 times as long.
>
>Anyway, yes that is unfortunately not surprising, and nobody has been able to
>crack this performance nut. The file repository is much faster if you do
>need to support large messages like that.
>
>Serge Knystautas
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org