PHP 4.0 Bug #7848 Updated: IMAP is very slow in CGI version

ID: 7848 User Update by: cahagn_o@epita.fr Old-Status: Feedback Status: Open Bug Type: Performance problem Description: IMAP is very slow in CGI version 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 ? Previous Comments: --------------------------------------------------------------------------- [2000-11-18 09:47:30] dbeu@php.net can you trace it back to a specific funtion? --------------------------------------------------------------------------- [2000-11-16 12:45:59] cahagn_o@epita.fr 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 ? --------------------------------------------------------------------------- Full Bug description available at: http://bugs.php.net/?id=7848