tony2001
TeaM PHPClub
PHP and Apache2 (c) Rasmus Lerdorf
Думаю, что прочесть очередное письмо Расмуса на тему "почему Apache2 - это плохо" будет полезно всем, включая даже тех, кто об этом уже знает.
------------------
From: Rasmus Lerdorf <[email protected]>
To: Lester Caine <------>
cc: [email protected]
Subject: Re: [PHP-DEV] Re: PHP and Apache2
Date: Tue, 15 Jun 2004 22:56:44 -0700 (Pacific Standard Time)
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
Думаю, что прочесть очередное письмо Расмуса на тему "почему Apache2 - это плохо" будет полезно всем, включая даже тех, кто об этом уже знает.
------------------
From: Rasmus Lerdorf <[email protected]>
To: Lester Caine <------>
cc: [email protected]
Subject: Re: [PHP-DEV] Re: PHP and Apache2
Date: Tue, 15 Jun 2004 22:56:44 -0700 (Pacific Standard Time)
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