|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7848 IMAP is very slow in CGI version
Submitted: 2000-11-16 12:45 UTC Modified: 2002-05-24 20:17 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: cahagn_o at epita dot fr Assigned:
Status: Not a bug Package: IMAP related
PHP Version: 4.0 Latest CVS (16/11/2000) OS: NetBSD, Linux, Windows 2k
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
44 + 1 = ?
Subscribe to this entry?

 [2000-11-16 12:45 UTC] cahagn_o at epita dot fr
I (with a friend) coded a webmail client in PHP (re-written
from Perl), available at:

It's very fast when PHP is loaded as a module with Apache (3
seconds to display a mailbox list from POP3 or IMAP server)
but the CGI version takes around 2 or 3 minutes to display

Even when disabling the default mailbox sorting feature, it
takes very long, but at least it won't fail with Windows
2k+Apache+PHP cgi with the 30 seconds max. exceeded.

I know this is a light bug report but I really wonder why
it's so slow, every other cgi with the same php binary is
very fast and the same webmail client coded with Perl is
much faster than the PHP equivalent whereas, generally
speaking, for my experience, my PHP scripts are faster than
my other scripts written in Perl, sh, etc. (except C :).
The accessed mail servers are local and I tried NetBSD,
Linux, Windows 2000.

I use the latest PHP from or


I've been using PHP for years now, debugging it a bit (the
binary is 2MB large on the NetBSD box) but this performance
problem is weird.

Thanks for any enlightenment. I hope you won't close this
bug report for bad php coding reason, I really think there's
a specific performance problem with CGI and IMAP, perhaps
the IMAP library that keeps on being reloaded ?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2000-11-18 09:47 UTC]
can you trace it back to a specific funtion?
 [2000-11-18 11:48 UTC] cahagn_o at epita dot fr
I think I identified the slowliness factor: big mails.

Testing with Apache 1.3.14 on NetBSD with PHP 4 latest snapshot and imap 2000 final on a PPro 200/256MB, mail server being POP3 and on the same LAN than the Web server:

 - mailbox with 15 small (< 10KB) messages: 15 seconds to load
 - mailbox with 4 messages and one being over 1MB: 30 seconds to load

When I test this on Apache 1.3.12 with PHP 4.0.3pl1 as module, IMAP server on the same LAN, on a Celeron 500/256MB:

 - mailbox with 4 messages and one being over 1MB: 3 seconds to load
-> very fast, the slowliness can't be identified when PHP is loaded as a module.

It seems like the imap lib is taking a lot of time to parse a _big_ message, that can be seen in CGI mode, not in module mode (at least for Apache).

I was wrong with imap_sort() being slow, it didn't change anything with a small mailbox, therefore with a big message, it increases a bit more loading the mailbox:

 - mailbox with 4 mails and one over 1MB: 30 seconds
 - same mailbox, imap_sort() commented out: 20 seconds.

In all these tests with PHP as CGI, it seems to take 3MB of RAM, no more, even with big messages.

I tested all these with IE5 and latest Mozilla which both handle HTML tables correctly unlike Netscape 4.x

ok, I finally traced it back to a specific function:

I use both imap_header() and imap_fetchstructure() functions for my webmail client:

 - imap_fetchstructure() commented, I get back to 15-20 seconds with my 4 mails' mailbox and one > 1MB.
 - imap_header() commented, I get 27 seconds (close to 30 seconds) with the same mailbox.

ok, to summarize this :)

=> With "big" mails (> 1MB or so), imap_fetchstructure() is very slow in CGI mode.

Well, no, I'm disappointed, I just tested with a 6 mails' mailbox which of 3 are 1MB large:

 - normal code: after 2 minutes, php error: "max. 30 seconds time exceeded at line 44" -> imap_fetchstructure()
 - imap_fetchstructure() commented, 1 minute
 - imap_fetchstructure() and imap_sort() commented, 45 seconds

I know MIME parsing is really a hard job, but why is the CGI version so much slower than the Apache module version ? Any idea ?
 [2000-11-29 19:05 UTC] cahagn_o at epita dot fr
I tested imap_fetchstructure() with the
pear/Benchmark/Timer.php package

with the following code:


$timer = new Benchmark_Timer;
$struct_msg = @imap_fetchstructure($pop, $mail);
$profiling = $timer->get_profiling();


Here're the results with PHP latest snapshot as CGI on a
PPro200, 256MB, and POP server being local, Apache 1.3.14,
PHP binary is 2MB large (without debugging symbols).
I load one mail at a time and see how long it takes for
imap_fetchstructure() to parse it depending on the size:

- 1KB, no attachment: 0.011 sec
- 78KB, no att: 0.225
- 68KB, 1 att: 0.225
- 1428KB, 1 att: 4 to 7 seconds !

With PHP loaded as a module, it's immediate (< 1 second)

During the test, the load was 0.6 and I tested several times
to be sure of the results.

So, to sum up:

imap_fetchstructure() is slow with big mails when PHP is
compiled as CGI.

 [2001-11-27 05:32 UTC]
Does this problem still occur with the 4.0.6, the latest RC( or the latest CVS?
 [2001-11-27 05:44 UTC] cahagn_o at epita dot fr
I can't reproduce this with 4.0.6, latest CVS or 4.1.0RC3 as they don't compile on my machine. Bug already reported on php-qa@.
However, the machine was upgraded, although it's still running NetBSD 1.5, Apache 1.3.20 and PHP 4.0.5 as CGI, it's now an Athlon 800 instead of a PPro200, and it's quite fast.

However, bug still exists as PHP as module is faster, and the IMAP code hasn't changed quite a lot since last year.
 [2002-01-16 07:23 UTC]
Does this error still occur with the lastest (CVS) version?
 [2002-01-16 08:07 UTC] cahagn_o at epita dot fr
I don't have a slow machine to test this anymore. We switched to a more powerful machine where the problem is harder to pinpoint.
Therefore, I guess the problem still remains as the IMAP source code hasn't changed since (besides additional features).
I won't be able to test this bug anymore as I won't have time for this.
 [2002-05-24 20:17 UTC]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 04:01:28 2024 UTC