булыжничек в огород PHP

[dil]

Why shouldn't I use Apache2 with a threaded MPM in a production environment?

"PHP is glue. It is the glue used 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. It needs a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working PHP needs ways to identify the problems and fix them quickly. When you make 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, feet of clay are introduced into PHP's system."

https://www.php.net/manual/en/faq.installation.php#faq.installation.apache2



"PHP - это клей. Клей, используемый для построения классных web приложений, склеивая дюжины сторонних библиотек и создавая впечатление одного согласованного целого, с помощью интуитивного и легко изучаемого языка. Гибкость и мощь PHP полагается на стабильность и устойчивость используемой платформы. Для склейки вместе ему необходимы работающая ОС, работающий web сервер и работающие сторонние библиотеки. Когда что-либо из этого перестаёт работать PHP нужны способы определения проблем и их быстрого исправления. Если вы усложняете низлежащую систему, не разделяя полностью потоки выполнения, не выделяя раздельные сегменты памяти и не предоставляя "песочницу" для игры для каждого запроса, то ваша PHP система увязнет в глине."

https://www.php.net/manual/ru/faq.installation.php#faq.installation.apache2


То есть, вместо внятного объяснения авторы почти открыто говорят: "мы написали такую какашку, что не гарантируем правильную работу с памятью, поэтому если уж вас угораздило её запустить, лучше делать это в отдельной песочнице, чтоб она вместе с собой не уронила соседние треды".

via nikulina

Comments

[romikchef]

"Мы написали" здесь нет. Здесь написано ровно противоположное - "dozens of 3rd-party libraries".
Проблем в мультитредном окружении не фиксируется уже много лет. Текст - баян.

[dil.livejournal.com]

Текст из официального документа по установке PHP. Уж что написали, то написали.

Если б дело действительно было в 3rd-party libraries, то в каких-то конкретных, которые и надо было перечислить поимённо. А "не разделяя полностью потоки выполнения, не выделяя раздельные сегменты памяти и не предоставляя "песочницу" для игры для каждого запроса" - это вполне однозначно понимается.

[romikchef]

Насколько я знаю - это дисклеймер, т.е. отмазка на случай.
Впрочем, и установка пхп модулем апача, и сам апач нынче устарели, так что, возможно, отсутствие проблем объясняется именно этим =)

[dil.livejournal.com]

а как нынче модно скрещивать php с апачем?

[romikchef]

Хороший вопрос, кстати
Очень модная, как раз, штука - http://php-fpm.anight.org/
На пхпконфе была весьма зажигательная презентация (последние две фотки), на которой автор как раз и описал последовательно проблемы установки модулем апача и CGI/FastCGUI, а затем - преимущества новой технологии.

Собственно, у пхп модулем ведь и своих проблем хватает - что для посещаемого сайта, что для шаред хостинга - куда более значимые, чем теоретическая нестабильность threaded MPM.

[dil.livejournal.com]

да-да, вот "Аварийный перезапуск всех процессов при случайном разрушении shared memory opcode cache если используется акселератор" и "Принудительное завершение подвисших процессов, если set_time_limit() не срабатывает" - это всё из-за 3rd-party libraries :)

если серьезно, насколько я понял, эта штука как раз и запускает php отдельными даже от апача процессами.

[romikchef]

Отдельными запускает и FastCGI.
Вообще php-fpm - это патч для нагруженных, пожалуй, систем, насколько я себе это понимаю. Поскольку исправляет главную проблему FastCGI, с которым акселераторы использовать практически бесполезно - свой кэш/опкод создается на каждый воркер. А php-fpm, как раз, эту ситуацию и исправляает.

Стоит быть немного внимательнее...

[insa.livejournal.com]

When you make the underlying framework more complex...

Осталось задаться вопросом что есть underlying framework для PHP applications...

Re: Стоит быть немного внимательнее...

[dil.livejournal.com]

я бы сказал, что underlying - это те библиотеки, которыми пользуется php. при чём тут апач с его тредами и процессами, который сам вызывает php, мне непонятно.

Re: Стоит быть немного внимательнее...

[insa.livejournal.com]

Отлично.

А теперь, представим, что у нас есть глобальная переменная во внешней библиотеке, скажем, в ZLIB, и два потока апача. Что будет если они оба, одновременно, полезут менять эту переменную?

Re: Стоит быть немного внимательнее...

[dil.livejournal.com]

конечно, будет плохо.
но именно по этому случаю у большинства библиотек существуют thread-safe версии. было бы дело именно в этом, имело бы смысл явно написать: убедитесь, что вы использовали именно эти версии библиотек при сборке php для работы в мультитредном апаче, а то будет плохо. а не обвинять какие-то абстрактные 3-d party в кривизне.

[insa.livejournal.com]

Хорошо, а теперь еще один простой вопрос — как убедиться, что все 3rd party библиотеки для PHP у нас thread safe на всех поддерживаемых платформах? К сожалению, проблема именно в таких штуках, и господа из Zend честно предупреждают, что Threaded MPM может не работать, и в данном Q/A объясняют почему.

Кстати, есть еще один хороший вопрос - а чем, вообще, Threaded MPM лучше Prefork'a под линуксом ,-)

[dil.livejournal.com]

ну, наверное, это не проблема авторов PHP, а того, кто этот php будет соибрать и использовать? из дело - предупредить как моджно более точно о возможных граблях. в данном же случае предупреждения насчет мультитредных библиотек нет, а есть туманные рассуждения.

лучше он, как всегда, тем, что создание/уничтожение треда - гораздо менее ресурсоёмкая операция, чем создание/уничтожение процесса.

[titov.livejournal.com]

Только чаще всего проблемы с падением в кору обнаруживаются почему-то на свежих версиях zend optimizer'а, а не этих dozens.

[dil.livejournal.com]

про оптимайзер, кстати, интересная мысль..