The open letter to Derick Rethans <derick@php.net>

On Wed, 16 Jun 2004, Lester Caine wrote:

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

For example, usleep() is not thread-safe on Solaris, and I can grep this function call from the source codes( I don't make a deep look, it may be my misunderstand...), but that explain how hard the review jobs are. "Lester Caine" <lester@lsces.co.uk> ???? news:20040616051414.56163.qmail@pb1.pair.com...

On Jun 18, 2004, at 2:16 PM, Sterling Hughes wrote:

^^^^^^^^^^^^^

I think it's kinda quaint that php.net runs a development version 4 point-releases behind current. George

SH>>Perhaps we should try running php.net and zend.com on php5 before we SH>>release? if we're not even eating our own dogfood yet, it seems SH>>premature to release. As for zend.com, I don't think this is going to happen before the release, if the release dates are what they are announced. Also, I understand PHP4 is far from being dead or unusable, so I don't see the reason why not to use it :)

At 10:28 20/06/2004, Stanislav Malyshev wrote:

We'll actually try to move something on www.zend.com to PHP 5 before the release, but definitely not the whole of it. It's a much more complicated site than www.php.net is, though, so it will take longer to actually migrate the whole of it. I don't think it reflects on the quality of PHP 5. It does reflect on the fact that migrating is a bit scary. Did anybody try to run www.php.net (a replica, that is) on PHP 5? Zeev

On Fri, 18 Jun 2004 21:04:36 +0200, Andi Gutmans <andi@zend.com> wrote:

What high traffic site is PHP5 RCx powering at the moment? Where is PHP5 being stress tested? How many people have deployed it for non-academic purposes? Running php.net on PHP5 isn't about making php.net run better, its about making PHP5 run better. In the PHP4 days, as you remember, we were running PHP4 on php.net since beta 1, why have we not switched to php5 since beta 1? I understand that deployment must come after the release for the majority of sites out there, but that is all the more reason that we should take every opportunity we have to test it in a real world circumstance before releasing it onto the public. -Sterling

On Friday 18 June 2004 02:04 pm, Andi Gutmans wrote:

Well if it's help which is needed, then I volunteer myself for anything that needs to be done to make it happen.