james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Updated: (JAMES-46) SMTP server against DB repository doesn't scale with message size
Date Wed, 14 Apr 2004 05:15:43 GMT
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


Mime
View raw message