Well, all of that is well and good, but still doesn't explain why the
performance would be so radically worse on the same server and same
mailbox in Roundcube versus Squirrelmail.
I'm not complaining about IMAP performance in general here. IMAP
performance on my server is fine, using every other client. Yes, I'm
in total agreement that IMAP is bound by resources such as disk and
RAM, and will bring a lesser server down if pushed far enough. The
problem here is that Roundcube should be more or less just as good as
any other client regarding this, and it isn't. Its radically worse,
and therefore there is a problem.
No, I'm not using NFS. Let's just assume, for the sake of keeping
this focused, that my IMAP server itself is behaving fine, and
working like a charm with local Squirrelmail and remote clients.
The question that needs to be answered is why Roundcube is not
behaving fine, when everything else is?
On Feb 24, 2006, at 1:46 PM, Benjamin Smith wrote:
I've seen the same performance problems with SquirrelMail and
mailboxes ~5k or greater on a beefy(Dual Opteron, 4GB RAM) v20z
server. I've also seen the problem on a webmail client I built,
and roudcube.
Here are a couple of questions for you:
Are you possibly accessing your messages via IMAP over NFS(uber bad
performance)?
Is your disk slow?
- If so can you modify the settings for the drive(e.g. hparm -Tt /
dev/sda to test disk speed )?
How much memory is available on the machine you're using?
Are you on a slow pipe?
The problem is more than likely a few things, hence the sporadic
"it works fine"...."no it doesn't" emails I'm seeing on this subject.
First and foremost.....DISK IO is *HEAVY* with IMAP! Performance
will degrade with large amounts of messages, when over NFS, or on a
slow drive.
Memory...hate to say it...but Apache/PHP likes to chew on memory.
Depending on your configuration(mod_php* vs cgi, etc) you will see
more performance issues when parsing thousands of messages over a
socket connection to an IMAP server.
Might also want to check your php.ini settings and look for
memory_limit. Default is 8M, you may want to tweak that...but
don't be too liberal..
Mark Edwards wrote:
On Feb 24, 2006, at 11:24 AM, phil wrote:
On Fri, 24 Feb 2006 11:09:47 -0800, Mark Edwards
<[EMAIL PROTECTED]> wrote:
Roundcube seems to have some difficulty dealing with large
mailboxes
(large meaning thousands of messages). It can manage indexing
one of
these, but if I try to actually show a message in a large
mailbox, it
basically hangs.
When this happens, the browser just sits there waiting for a reply,
and I can do a 'top' on the server and watch the apache process
just
eat up memory until it finally dies.
It seems that Roundcube is digging through the mail and not
releasing
memory in some way, which becomes a problem as the mailbox size
gets
large. At least that's my theory.
Does anyone else observe this? This is with Apache 1.3.34, PHP
5.1.2, MySQL 4.1.18 and Cyrus 2.2.12, running on FreeBSD 4.11p14.
Is your SMTP server on the same box? If so, turn off caching in
the config, that helped me out. For record, I have ~1100
messages in my Roundcube folder, and switching from/to this
directory seems quick. Oh, and I"m on Freebsd 6.0 with mySQL
4.x, Apache2, Dovecot 0.9
If that doesn't help - what does /var/log/maillog say when this
is occuring?
Caching is off, and I don't see what it has to do with SMTP. Its
not switching to/from the directory that causes the problem. Its
viewing a message within a directory that has thousands of
messages. Viewing a message in a box with 1000 or so messages is
just fine on this end. I can view a message in a box with 3000
messages, but it takes a bit longer. If I try to view a message
in a box with 7000, it bogs down and eventually dies with a
"Request timed out!" message in the Roundcube display.
I am not running anything that logs to /var/log/maillog, but my
Cyrus log and my Apache log for the relevant processes are
uneventful. Basically, Roundcube seems to be doing something
that eats up memory and time relative to the size of the mailbox
being accessed, and if the box is sufficiently large, it bogs
down my system and times out.
--
Mark Edwards
--
Mark Edwards
