Well written & well explain Rasmus. I have seem this questions been asked many times in a few mail list. Someone should post this reply into a FAQ page or the Manual in www.php.net
Joe Lee. -----Original Message----- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 6:57 AM To: Lester Caine Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: PHP and Apache2 On Wed, 16 Jun 2004, Lester Caine wrote: > Lester Caine wrote: > > What I should have added is:- > > What are the problem modules? :) Ah, you see, if we knew that we would just fix them and be done with it. The problem here is not as simple as people like to make it sound. Time and time again I see the /. mentality where people berate PHP developers for being stupid and stubborn for not just "fixing PHP" so it is stable and robust with Apache2. I have explained this a number of time, but here we go again. Apache2 is a complete rewrite and a complete architecture change from Apache1. It's not like going from PHP3 to PHP4 or from PHP4 to PHP5. There is a lot of code that is common, and certainly the base architecture of PHP hasn't changed for years. So comparing Apache1 vs. Apache2 to PHP4 vs. PHP5 makes no sense. As far as I am concerned I see no reason for Apache1 development to stop. The architecture has been proven over the years and the code, while somewhat unwieldy in places, is a known entity. PHP from the very early days was designed against this basic Apache1 architecture and works extremely well running under it. The major feature that draws people to Apache2 is threading. On Windows where most basic libraries are, and must be, threadsafe, Apache2 does actually make sense and it would be good to work out the kinks on that platform. However, on UNIX there are a lot of basic libraries where thread safety is an unknown. And here I am not talking about PHP extensions, I am talking about 3rd-party libraries underneath our hundreds of extensions. Whether any one 3rd-party library is threadsafe is really hard to determine. There are a lot of variables involved, including which OS, which version of the OS, which libc, which version of that libc and on some platforms even the compiler flags used to compile these things. And to make it even more fun, tracking down a thread safety problem is damn well near impossible. Hundreds of people may well post to this list that Apache+PHP+ext/foo works perfectly for them, but maybe they are only getting about a million hits a day. Then another user comes along who gets 100 million hits a day and uses a fast dual-cpu machine and everything blows up because now suddenly the window for some tiny race condition has been made much larger due to the faster cpu speeds, the second cpu and the higher frequency of requests. And the bug report we get from this user will be something along the lines of: It don't work sometimes. Most of the times it works fine, but then every now and then it just don't. The error is different each time and I have no idea how to reproduce it, but fix it right away!!! What do you suggest we do about these? I tracked one of these down a couple of years ago. Someone was using an early version of Apache2 with the PostgreSQL libpq client library. The PostgreSQL developers swore up and down that their library was threadsafe and I spent a whole day eliminating libraries one by one. Luckily this particular problem was somewhat reproducable. If I banged hard enough at one section which created new accounts every now and then an account would end up with a bogus password entry and the user wouldn't be able to log in. It turned out that libpq was using the system's crypt() function which was not threadsafe. So the account creation which used something line INSERT INTO users ... CRYPT($password)... would mess up when 2 or more threads were trying to do this at the same time. This wasn't PHP's fault in any way, it wasn't really PostgreSQL's fault either, but it was still broken. I can give you a number of (fixable) technical reasons why I don't think Apache2+PHP is a good idea in a production environment, but setting those aside it really boils down to one simple concept: PHP is glue. It is the glue we use to build cool web applications by sticking dozens of 3rd-party libraries together and making it all appear as one coherent entity through an intuitive and easy to learn language interface. The flexibility and power of PHP relies on the stability and robustness of the underlying platform. We need a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working we need ways to identify the problems and fix them quickly. By making the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, we introduce feet of clay into our system. And yes, you could use the prefork mpm with Apache2 to avoid the threading, and yes you could use a standalone fastcgi mechanism to avoid the threading, but you are going out of your way to avoid the defining characteristic of the web server you have decided to use. At this point in its development, I still maintain that you are better off simply sticking with Apache1 for serving up PHP pages with the one caveat that Apache1 sucks pretty badly on Windows. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
