Форум PHP

Уважаемый J.Lex.

Прошу Вас еще раз внимательно перечитать ответы cheopsa и Кузнецова М.В. Если Вы это сделаете, то несомненно найдете ответы на Ваши вопросы.

В том числе прошу перечитать выложенные Вами же рекомендации Расмуса Лердорфа.

но а тогда как же с рекомендациями от разработчиков самого PHP5?

--------------------
Почему разработчики PHP не рекомендуют использовать его с Apache 2.x?

1. Apache2 по всем тестам работает процентов на 15-20 медленнее Apache 1.3*. Этот факт давно известен, в том числе и разработчикам Apache. Выигрыш от его использования может быть только на очень больших сайтах и заключается только в меньшем расходе памяти при большой нагрузке (100 процессов httpd жрут памяти больше, чем 100 нитей Apache2). В Apache2, несмотря на то, что разработчики называют его стабильным, довольно часто находят довольно серьезные баги. Это объяснимо, учитывая то, что код Apache2 еще достаточно новый, в отличие от вылизанного временем кода Apache1.3

2. В PHP полно расширений, при программировании которых не была применена практика безопасного программирования для нитей (thread-safe). Поэтому, даже если ядро языка перестанет быть экспериментальным для Apache2, никто не гарантирует, что любое из расширений не сможет вызвать крах системы.

3. Наконец, последняя версия Apache2 нисколько не "свежее" последней версии ветки 1.3.

>зачем рекомендовать Apache2.x.x если разработчики PHP5 не
>рекомендуют !
> прочитайте внимательно
Спасибо за совет. Прочитал. Вижу, что глубокоуважаемый Расмус Лердорф говорит о том, что под Windows Apache 2 функционирует вполне нормально. А наша статья и наши советы как раз и посвящены установке под Win. Прочитайте внимательно. В том числе и тот текст, который Вы выложили.

Ув. J.Lex!
Элементарные правила уважения к посетителям форума требуют, если уж Вы приводите английский текст, максимально качественно и близко к тексту переводить все то, что Вы привели.

PHP не отделим от UNIX, мало кто отважится использовать боевой сервер с Apache+PHP под управлением Windows - поэтому речь и идёт о том, что PHP (кстати, не только 5, но и 4) не следует использовать совместно с Apache 2 под UNIX.

Однако реалии современного мира таковы, что 98% пользоваетелей (в том числе и PHP-разработчиков) работают под Windows. Т.е. сначала PHP-скрипты разрабатываются под Windows и лишь затем отправляются на сервер под управлением UNIX.

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.

Нити UNIX и Windows различиются, в Windows они более защищены - сбой в потоке не приведёт ни к краху системы, ни даже к краху программы (если это не основной поток процесса), поэтому здесь и говорится о том, что использовать Apache2 под Windows действительно имеет смысл.

Кроме того, упор в приведённом выше тексте делается на то, что проблемы возникают в основном лишь со сторнними расширениями PHP, в то время как стандартные расширения, достаточно надёжны. Поэтому использование PHP с Apache 2 под Windows (в CGI-варианте) вполне оправдано и вряд ли может предподнести сюрприз. В UNIX может быть, помоему только Fedora Core использует Apache 2...

это разное мнение,но вот именно разработчики PHP5 рекомедуют Apache 1.x.xx поскольку Apache2 еще не совсем подходит для PHP5!также это говорю не только я!

Хм.. что-то я не припомню, чтобы мы где-либо советовали использовать Apache 2.0.x под UNIX. Мы действительно советуем начинающим Web-программистам использовать Apache 2.0.x для локального тестирования под Windows (в CGI версии), так как он менее капризен и более удобен версии 1.3.x в настройке конфигурационного файла. Как раз против этого-то Rasmus и не выступает.

Ув.Создатели книги
зачем рекомендовать Apache2.x.x если разработчики PHP5 не рекомендуют !,

прочитайте внимательно

From: Rasmus Lerdorf <rasmus@php.net>
To: Lester Caine <------>
cc: internals@lists.php.net
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