ID: 7848 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: IMAP related Operating System: NetBSD, Linux, Windows 2k PHP Version: 4.0 Latest CVS (16/11/2000) New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2001-11-27 05:32:01] [EMAIL PROTECTED] Does this problem still occur with the 4.0.6, the latest RC(http://download.php.net/~zeev/php-4.1.0RC3.tar.gz) or the latest CVS? ------------------------------------------------------------------------ [2000-11-29 19:05:24] [EMAIL PROTECTED] I tested imap_fetchstructure() with the pear/Benchmark/Timer.php package with the following code: [...] $timer = new Benchmark_Timer; $timer->start(); $timer->set_marker("42"); $struct_msg = @imap_fetchstructure($pop, $mail); $timer->stop(); $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. ------------------------------------------------------------------------ [2000-11-18 11:48:23] [EMAIL PROTECTED] 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-18 09:47:30] [EMAIL PROTECTED] can you trace it back to a specific funtion? ------------------------------------------------------------------------ [2000-11-16 12:45:59] [EMAIL PROTECTED] I (with a friend) coded a webmail client in PHP (re-written from Perl), available at: http://nocc.sourceforge.net/ 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 anything. 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 snaps.php.net or php4win.de See http://www.epita.fr:8000/~cahagn_o/php/info.php 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 ? ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=7848&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
