Fastcgi в php

Question

[sajgak]

Собственно интересует наличие сабжа в том виде, в котором он реализован в Си. Текущая реализация, входящая в дефолтную сборку кажется настолько кастрированной, что использовать ее помоему совершенно нет смысла. Или я ошибаюсь?

Так же паралельно хотелось бы наконец уяснить для себя есть ли какое то преимущество в производительности у fastcgi по сравнению с mod_php в апаче, т.к. продолжительное гугление ни к чему конкретному не привело.

Спасибо.

Answer 1

[zizop]

До сих пор не утихают споры по этому вопросу. Однозначного мнения нет, всё зависит от задачи, и от того, насколько ваш код оптимизирован к работе в fastCGI режиме. Вот материалы, которые помогут вам разобраться в теме:
— Статья Дмитрия Котерова про php fast-cgi
— Вриант от создателя phpDaemona
— Статья по настройке php5-fpm
— Статья Ильи Кантора по скрещиванию Symfony и Fast-Cgi

По поводу тестов и сравнения:
— php-fpm VS apache2+mod_php
— Apache + mod_php compared to Nginx + php-fpm
— Comparing Nginx+PHP-FPM to Apache-mod_php
— Битва PHP: Apache vs PHP-FPM

Некоторые соображения:
Вся технология PHP-FCGI базируется на чем угодно, только не на том, что из себя представляет fast cgi для таких например языков как Perl & C со своими интерфейсами скриптинга.

Если уравнять условия apache и php-fpm, php-fpm единственное в чем выигрывает, то это в памяти, ито за счет двух дополнительных процессах апача. Остальные выигрыши довольно сомнительны.

Если с апача убрать обработку статики и всего лишнего (например с помощью nginx), он довольно шустро обрабатывает скрипты.

С другой стороны, в PHP-FPM довольно красиво реализована схема chroot’а и запуска из под отдельных юзверей, что повышает безопасность. Но он проигрывает в IPC, т.к. пока не умеет изменять количество воркеров пропорционально нагрузке. Если поставить слишком много воркеров, будет overhead по CPU и памяти (за что грешат на апач), если поставить слишком мало – будут отказы в обслуживании. Ну впрочем, кому резонно вручную следить за процессами FPM, те этим занимаются.

Answer 2

[Пума Тайланд]

Ну он может работать от разных пользователей.
Его можно прикрутить к нгинксу и убрать апач.
Вы про php-fmp?
Из коробки в пхп по моему нет fastcgi.
И совершенно не понял в чем его кастрированность то?

Comments

[sajgak]

1. про разных пользователей- это врятли относится к производительности) безопастность — да, но я не о том.
2. сейчас у меня работает связка nginx+apache2+mod_php, убрать апач готов только если найду нормальное fastcgi решение.
3, 4, 5. fpm — умеет спаунить необходимое кол-во воркеров в зависимости от нагрузки, но вот под каждый запрос всеравно все действия отрабатываваются с нуля. Поэтому, хотя и заявленно, что пых может работать в fastcgi на самом деле это не так.

[Пума Тайланд]

Ну а чем вас fmp не устраивает? оно в любом случае будет быстрее чем апач с пхп, ну прикрутите ещё еакселератор и будет у вас кеширование исполняемого кода на уровне пхп.

[sajgak]

акселератор так же присутствует) вся прелесть fastcgi — в единовременной инициализации приложения при старте воркера. насчет того, будет ли fpm быстрее mod_php — не уверен. Памяти меньше сьестся из за отсутствия апача — да, а вот производительность нигде однозначного ответа не встречал

[Aleks]

в 5.3 ветке fpm интегрирован в дистрибутив сразу

[Пума Тайланд]

ну смигрирую на центос 5.6 или 6.0 и посмотрим как оно работает на деле.

Answer 3

[Tonik]

По умолчанию настоящего FastCGI в PHP нет. По факту скрипты заново инициализируются при какждом запросе. Тут может помочь какой то опкешер, но к теме вопроса это отношения не имеет.

Есть проект phpdaemon, который может работать как FastCGI server. На хабре о нем не редко пишут. Вот например попытка перевести проект на симфонии на него habrahabr.ru/blogs/php/103875/.

При всем моем уважение к phpdaemon (без сарказма), я бы побоялся выпускать это в продакшен.
1. Сколько людей стоит за этим проектом? Насколько безглючный код? Не надоест ли автору завтра заниматься этим проектом? Лист рассылки не выглядит слишком активным…
2. Если у вас есть уже готовый код, большой шанс что его придется допиливать.

И тд. Мое имхо, что PHP годами был плохо приспособлен к такому использованию. Да стало лучше, но еще пройдет не мало времени, прежде чем вся инфрастуктура PHP будет приспособлена для true FastCGI приложений.

мое мнение — если хотите настоящий FastCGI, то PHP пока не лучший выбор.

Comments

[sajgak]

насчет допиливания приложения под fastcgi это ясен пень. Если бы он был нормально реализован — допилил бы с удовольствием. Про phpDaemon слышал… но как то один разработчик не внушает доверия в плане стабильности. Никаких похожих проектов не наблюдается?

[sajgak]

Кстати, спасибо за ссылку. Довольно интересно. Если б какой то «недвольный» только что не скинул мне кармы — плюсанул бы:)

[Tonik]

Ну надо сказать что сам разработчик вызывает ощущение человека талантливого и трудолюбивого. Но вот то что он один, сильно отпугивает.
О похожих проектах не слышал. Да даже если они и появятся, то пройдет минимум год прежде чем будут готовы к использованию. Так что, с FastCGI в PHP все еще не радужно.

Answer 4

[Алексей Шеин]

Еще есть такая штука: github.com/indeyets/appserver-in-php, реализация WSGI на PHP.

Answer 5

[zoxa]

Использую php fast cgi на нашем проекте. но правда только конкретно для определенной части приложения.
нам надо было связать высоко нагруженную часть приложения (трэкинг переходов по ссылкам) с IBM MQ Web Sphere и с MySQL

Пришлось допилить руками код на с. но в итоге получили следующее:
Каждый сервер apache поднимает (взависимотси от нагрузки) от 5 до 100 форков приложения и каждый форк держит постоянные соеденения с MQ или с MySQL. Что дало прирость в скорости и решило проблему с кол-вом открытых соеденений.

Полностью переключиться на fast-cgi не получилось. Некоторые компоненты не захотели работать под fast-cgi частью поэтому пришлось разбивать на части.

Comments

[sajgak]

У меня база полностью ограждена кешем, поэтому стандартный цикл — обработать запрос — получить данные из кеша — сформировать html. При таком подходе fastcgi по идее должен дать хорошую разгрузку. Наверное всеже буду использовать phpdaemon чуть попозже.