ID: 48839
User updated by: pkwan at advsofteng dot net
Reported By: pkwan at advsofteng dot net
Status: To be documented
Bug Type: Scripting Engine problem
-Operating System: win32 only
+Operating System: All OS
PHP Version: 5.3.0
New Comment:
I would like to add that this problem is not win32 only, but affects
all OS. (I changed the OS field to "All OS".) As CGI is important for
non-Windows OS, so I think this issue is important.
Previous Comments:
------------------------------------------------------------------------
[2009-07-08 11:20:45] pkwan at advsofteng dot net
Your point about the performance of "dl" is valid for PHP as an Apache
module. However, for CGI, the reverse is true. "dl" is much more
efficent than "php.ini".
If you have tested it in a real and typical CGI environment, you can
see that CGI PHP becomes very slow without "dl".
In a typical PHP environment, there may be around 10 to 20 extensions.
Without "dl", the extensions must be listed in "php.ini". It means the
CGI PHP must load all these 20 extensions running each PHP script
(remember, in CGI, the PHP is restarted for each request), even if a
typical PHP script only used none or a few extensions. This is the cause
of the slowness.
I know "dl" is slower than "php.ini" if PHP is an Apache module, but it
is much faster than the "php.ini" for if it is a CGI.
For the "avoidance of crash", may be you are correct, as I did not have
enough experience in "avoidance of crash". However, I suspect much of
the crashing problems is when PHP is when it is used as an Apache
module. It should be much more stable in CGI.
It is because CGI is never multi-threaded, and it is always used by one
script only. Remember in CGI, each script is handled by a separate PHP
process, which is only used once for that instance of the script. It is
hard to see why "dl" can be more crash prone than using "php.ini" in
CGI.
Finally, even if the PHP dies, it affects only that instance of the
script. For CGI, the PHP process will terminate anyone at the end of the
script. So it should not affect the stability of the system.
------------------------------------------------------------------------
[2009-07-08 10:40:58] paj...@php.net
Yes, I'm sure. There are reasons why it has been done (avoid crashes
being one of them). Also I don't see how performance can be affected by
the dl removal (using dl is slow) :)
------------------------------------------------------------------------
[2009-07-08 10:37:28] pkwan at advsofteng dot net
Are you sure you want it do be a doc bug?
CGI PHP will be very inefficient and has very poor performance without
"dl".
It is because in CGI, PHP needs to be restarted for every PHP request.
Without "dl", all extensions have to be defined in "php.ini". It means
PHP needs to load all extensions for every PHP request, even if the
extensions are not used by a script.
I would think it is reasonable to load extensions using "php.ini" for
the PHP Apache module, because PHP is only started once as an Apache
module. However, for CGI PHP, it is a poor design to load extensions
using "php.ini". Using "dl" is much more reasonable.
In my opinion, the original documentation to allow "dl" to be used for
"CLI" and "CGI" seems to be a good design.
------------------------------------------------------------------------
[2009-07-08 09:21:21] paj...@php.net
moved this bug as a doc bug.
------------------------------------------------------------------------
[2009-07-08 06:36:27] pkwan at advsofteng dot net
But you are using php-cgi in the command line, not as a CGI.
If you actually used php-cgi as a CGI, the code in "cgi_main.c" will
detect that it is used as a CGI (by checking the CGI environmental
variables), and disables "dl". This is done by the following code in
"cgi_main.c".
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48839
--
Edit this bug report at http://bugs.php.net/?id=48839&edit=1
