Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 197
Мммм… php-fpm?
Круто, что интересно, сервер для php разрабатывается на самом же php. :)
Вечером посмотрю повнимательнее…
Вечером посмотрю повнимательнее…
угу только готовьтесь к тому что программировать придется иначе.
И еще можно хоть какие-то данные по поводу выйгрыша в производительности?
И еще можно хоть какие-то данные по поводу выйгрыша в производительности?
Выигрыш в производительности напрямую зависит от приложения (выигрыш в избавлении от еже-запросной инициализации).
Страничка-пример легко выдерживает 5000 запросов в секунду на 20 воркерах :-)
Страничка-пример легко выдерживает 5000 запросов в секунду на 20 воркерах :-)
а можно привязывать вопрос и воркера? чтоб не переиницыировать состояния некоторых объектов
ой опечатался запрос тоесть например ссесию к воркеру привязать?
Я думал об этом, однако понял что так делать не стоит, т.к. воркер может быть занят, может умереть, и т.д. и т.п. Для хранения объектов лучше использовать кластер Redis/Memcache.
Однако, общесистемные объекты имеет смысл кешировать (например, показания статистики, которая обновляется раз в 5 секунд). То есть хранить в Redis/Memcache, но обновлять в локальной памяти лишь переодически.
Однако, общесистемные объекты имеет смысл кешировать (например, показания статистики, которая обновляется раз в 5 секунд). То есть хранить в Redis/Memcache, но обновлять в локальной памяти лишь переодически.
а без fastcgi сколько?
Не знаю, но разница будет не особенно велика по причине простоты примера, там инициализация состоит из одной строчки: $counter = 0;
тада либо уберите этот маркетинговый мусор, либо сделайте нормальный пример.
>Страничка-пример легко выдерживает 5,000 запросов в секунду всего на 20-ти воркерах.
То есть, получаем 150 запросов в секунду на 1 «воркере».
Я конечно не знаю какое там железо, но учитывая крайнюю простоту примера можно быть уверенным, что вариант без fastcgi проявит себя не хуже, а может быть даже и лучше.
Лучше сделайте пример посложнее, с массивной инициализацией (например, с подгрузкой конфигов), или с использованием долгоживущих объектов в памяти (например пул баннеров). Вот тут-то технология fastcgi проявит себя с лучшей стороны.
То есть, получаем 150 запросов в секунду на 1 «воркере».
Я конечно не знаю какое там железо, но учитывая крайнюю простоту примера можно быть уверенным, что вариант без fastcgi проявит себя не хуже, а может быть даже и лучше.
Лучше сделайте пример посложнее, с массивной инициализацией (например, с подгрузкой конфигов), или с использованием долгоживущих объектов в памяти (например пул баннеров). Вот тут-то технология fastcgi проявит себя с лучшей стороны.
сорри, имел в виду 5000 / 20 = 250 запросов в секунду ))
P.S. весьма полезное дело делаете, думаю, многим пригодится
P.S. весьма полезное дело делаете, думаю, многим пригодится
Ну во-первых это всего на 8 воркерах nginx'а и 20 воркерах phpFastCGI, во-вторых последний тест на них же.
Requests per second: 5183.23 [#/sec] (mean)
Процессор вообще не загружен. Если поставить 32 воркера nginx и 300 воркеров phpFastCGI… результат будет чуток другой.
Вообще эти цифры приведены для того чтобы людей не терзали сомнения относительно распределения нагрузки и скорости… Ясен пень что надо тестировать на реальной системе и там уже воспринимать данные бенчмарка как объективные показатели предельной нагрузки. А сейчас эти данные можно лишь сравнивать и радоваться новым оптимизациям :-)
Requests per second: 5183.23 [#/sec] (mean)
Процессор вообще не загружен. Если поставить 32 воркера nginx и 300 воркеров phpFastCGI… результат будет чуток другой.
Вообще эти цифры приведены для того чтобы людей не терзали сомнения относительно распределения нагрузки и скорости… Ясен пень что надо тестировать на реальной системе и там уже воспринимать данные бенчмарка как объективные показатели предельной нагрузки. А сейчас эти данные можно лишь сравнивать и радоваться новым оптимизациям :-)
да hello world из ZF вывести — чем не тестирование
где про это можно более детально почитать
те какие процессы, сайты лучше запускать через fastcgi а какие по средствам mod_php
те какие процессы, сайты лучше запускать через fastcgi а какие по средствам mod_php
угу только готовьтесь к тому что программировать придется иначе.
Ничего страшного, в Django всё работает по такому же принципу :) Только там используется flup и работа с FastCGI/WSGI скрыта.
Пример работает чудовищно быстро!
напомнило мне анекдот университетский
Приходит студент в лабораторию и заявляет:
— я дома собрал по чертежам в интернете торсионную установку и получил выдающиеся результаты
Лаборант: — да и какие же?
— Я обработал торсионным полем кусок меди и он стал в 10 раз более проводим!
Л: — Хм очень интересно, можно взглянуть?
С: — да конечно, вот он!
Л: приходите завтра
Студент утром ждет лаборанта, а когда тот приходит допытывает его
— ну как вы зафиксировали мои выдающиеся рузультаты?
Л: -да это медь и проводимость у нее как у меди
С: — НЕ МОЖЕТ БЫТЬ вы хотите украсть мой экземпляр!
Л: — не паникуйте вот ваш кусок меди заберите его.
С: — ну как же так?
Л: — если не секрет, то чем вы меряли сопротивление проводника
и тут студент гордо достает из кармана китайский тестор у которого погрешность в разы больше чем сопротивление такого малого куска меди и гордо заявляет
С: — ЭТИМ!
Приходит студент в лабораторию и заявляет:
— я дома собрал по чертежам в интернете торсионную установку и получил выдающиеся результаты
Лаборант: — да и какие же?
— Я обработал торсионным полем кусок меди и он стал в 10 раз более проводим!
Л: — Хм очень интересно, можно взглянуть?
С: — да конечно, вот он!
Л: приходите завтра
Студент утром ждет лаборанта, а когда тот приходит допытывает его
— ну как вы зафиксировали мои выдающиеся рузультаты?
Л: -да это медь и проводимость у нее как у меди
С: — НЕ МОЖЕТ БЫТЬ вы хотите украсть мой экземпляр!
Л: — не паникуйте вот ваш кусок меди заберите его.
С: — ну как же так?
Л: — если не секрет, то чем вы меряли сопротивление проводника
и тут студент гордо достает из кармана китайский тестор у которого погрешность в разы больше чем сопротивление такого малого куска меди и гордо заявляет
С: — ЭТИМ!
Это, кстати, не анекдот, а случай из жизни. Только участвовали не лаборант со студентом, а целая комиссия с одной стороны и горе-изобретатель с другой. Читал расшифровку протокола заседания комиссии — практически, слово в слово. Увы, ссылку на источник не дам, ибо потеряна за давностью лет.
Ага, пруфлинк
Наш супер-компьютер настолько быстр, что выполняет бесконечный цикл за 15 секунд :)
Это супер-мега крутотень.
Мы тут с другом тоже пытаемся такую штуку наваять. Правда пока у нас все еще даже до альфы не дошло.
Немножко кода мона глянуть на: sourceforge.net/phastcgi
Мы тут с другом тоже пытаемся такую штуку наваять. Правда пока у нас все еще даже до альфы не дошло.
Немножко кода мона глянуть на: sourceforge.net/phastcgi
Ой. нета линка: sourceforge.net/projects/phastcgi/
Посмотрел. Думаю, будет хорошо если вы присоединитесь.
За приглашение спасибо :) Но мы пока все таки лучше сами. Участие в таком проекте с незнакомыми людьми — все таки большая ответственность. Не хотелось бы подписываться под тем чего заранее не сможешь выполнить.
Да и 3 человека для такой задачи както многовато. Будем мешать друг другу и тянуть одеяло :))
Я думаю лучше почаще заглядывать друг другу в код и находить там интересные вещи. Например функции pack/unpack для меня были большим открытием :)
Да и 3 человека для такой задачи както многовато. Будем мешать друг другу и тянуть одеяло :))
Я думаю лучше почаще заглядывать друг другу в код и находить там интересные вещи. Например функции pack/unpack для меня были большим открытием :)
все присоединяйтесь к разработке phpfastcgi от TravisBickle
Да, дня за 4 написал фактически :-) Значительно раньше будет Stable-релиз.
Ну на самом деле мы ее делаем тоже не так дого. И не так много как хотелось бы :) Если обратить внимание на статистику коммитов то реально этим делом занимались тока 3 дня :)
Но мы под впечатлением и теперь будем усиленней пендалить :)) Идея класная. Ну и не может же быть так что бы плохая идея пришла в голову двум людям одновременно? Так бывает только с плохими идеями :)
Но мы под впечатлением и теперь будем усиленней пендалить :)) Идея класная. Ну и не может же быть так что бы плохая идея пришла в голову двум людям одновременно? Так бывает только с плохими идеями :)
а зачем вести несколько проектов если можно объединить усилия?
Идея мне пришла очень давно, как только я увидел PHP-FPM, однако руки не доходили приняться за реализацию.
А надо ли педалить? =)
А надо ли педалить? =)
да здравая и очень логичная идея удивительно что разработчикам пхп она досих пор таковой не кажется — вот это да удивительно
А в чём разница ваших выкрутасов с пыхпыхом и обычного php-fpm в связке с акселератором? (который кеширует «откомпиленный» ПХП код?)
Имхо это будет даже медленнее....:)
Имхо это будет даже медленнее....:)
А вы хотя бы первый абзац прочитали?
Угу. Даже в код заглянул. Прежде чем минусовать, попробуйте включить голову и найти хотя бы одно отличие.
PHP-FPM использует (на сколько я знаю, префорк) в этом случае — используется всё тот же префорк. Только ручной.
Идём далее — код внутри цикла — всё тот же висящий всё время в памяти ОП-КОД.
Где хотя бы одно преимущество?
Перед тем, как начинать развивать проект дальше, погонять тесты слабо?
PHP-FPM использует (на сколько я знаю, префорк) в этом случае — используется всё тот же префорк. Только ручной.
Идём далее — код внутри цикла — всё тот же висящий всё время в памяти ОП-КОД.
Где хотя бы одно преимущество?
Перед тем, как начинать развивать проект дальше, погонять тесты слабо?
А коннект к базе данных у Вас тоже в оп-код закеширован? ;-)
php.net/mysql_pconnect
cпасёт отца русской демократии.
cпасёт отца русской демократии.
спасет, тока одно комплексное решение, а другое частное
К примеру, в реализации клиентов для Redis/Memcached нету pconnect'а.
А зачем там pconnect?
Мемкейчед сервер разумно ставить на том же сервере, или как минимум в локалке.
И накладные расходы на этот коннект будут минимальны. А следовательно и оптимизировать тут нечего.
Я считаю, что оптимизация ради оптимизации зло. И оптимизировать нужно узкие места. Те — которые тормозят.
Хотя ваш «проект» имеет место на жизнь. Только, боюсь, полезность стремится к нулю :(
Мемкейчед сервер разумно ставить на том же сервере, или как минимум в локалке.
И накладные расходы на этот коннект будут минимальны. А следовательно и оптимизировать тут нечего.
Я считаю, что оптимизация ради оптимизации зло. И оптимизировать нужно узкие места. Те — которые тормозят.
Хотя ваш «проект» имеет место на жизнь. Только, боюсь, полезность стремится к нулю :(
Я посмотрю, Вы не работаете с highload'ом. Вот ведь дураки сидят в Facebook — кучу времени потратили на исправление memcached для лучшей работы с UDP, чтоб убрать overhead TCP-коннектов? ;-)
> Я считаю, что оптимизация ради оптимизации зло. И оптимизировать нужно узкие места. Те — которые тормозят.
Вы безусловно правы. Сайты-визитки, домашние странички и прочее, куда ходят два с половиной человека в день можно писать практически как угодно и не думать об оптимизации. Данный же топик обращен к тем людям, кто занимается несколько другим классом задач.
> Я считаю, что оптимизация ради оптимизации зло. И оптимизировать нужно узкие места. Те — которые тормозят.
Вы безусловно правы. Сайты-визитки, домашние странички и прочее, куда ходят два с половиной человека в день можно писать практически как угодно и не думать об оптимизации. Данный же топик обращен к тем людям, кто занимается несколько другим классом задач.
Давайте вы не будете давить своим мнимым авторитетом?
При чём здесь фейсбук? В фейсбуке, возможно, оверхеад TCP коннектов и стало узким местом. Только сомневаюсь я, что в каком-либо из ваших проектов эта проблема имеет место быть.
Без разницы какие это сайты. Высоко-нагруженные или сайты с посещением 1 чел\сутки.
Мне вот интересно, вы математические операции битовыми ещё не заменяете? А то ведь кучу времени сэкономите… Советую…
При чём здесь фейсбук? В фейсбуке, возможно, оверхеад TCP коннектов и стало узким местом. Только сомневаюсь я, что в каком-либо из ваших проектов эта проблема имеет место быть.
Без разницы какие это сайты. Высоко-нагруженные или сайты с посещением 1 чел\сутки.
Мне вот интересно, вы математические операции битовыми ещё не заменяете? А то ведь кучу времени сэкономите… Советую…
Есть люди которые просто чего-то не понимают, но отказываются это признавать.
Это — кривое расширение ;-)
Посмею заметить — это оупенсоурс решение.
И если даже оно кривое — ни кто не мешает его сделать ровным.
И если даже оно кривое — ни кто не мешает его сделать ровным.
ни кто не мешает его сделать ровнымКапитан, мы рады что вы здесь. Но посмотрите внимательнее, речь идет о существующих решениях, а не о гипотетических.
Это решение тоже существует. И оно точно такое же кривое как и то, что предлагается здесь. (возможно пока).
Так почему бы не вложить время в действительно 100% правильно работающий код?
Так почему бы не вложить время в действительно 100% правильно работающий код?
Вот хороший комментарий.
не не не боже упаси вас от этого — почитайте сколько из за этого багов вылезает. конекты неконтролируемо рвутся и решать это трудно.
погонять тесты я уверен необходимо, но идеологически тут во первых может быть инициализация соединений с БД например, установка всех начальных значений все это помноженное на огромное количество инициализаций дает прирост. Вы сами подумайте.
1. создание объектов и агрегатов объектов (пересоздавать нада только нужные + вы можете создавать коллекции)
2. Открытие соединений к БД
3. Локальный стек статистики, который вы можете чистить регулярно а не каждый запрос.
я уверен придумать места где будет экономия можно еще — это только основные.
а вообще на основе этой штуки фактически создается событийная машина полноценная, с циклами состояний (например агрегаторы фидов рекламных где запросы очень долгие к сторонним серверам делаются влет), а на основе PHP-FPM вы этого не сделаете именно из за ежекратного перезапуска
1. создание объектов и агрегатов объектов (пересоздавать нада только нужные + вы можете создавать коллекции)
2. Открытие соединений к БД
3. Локальный стек статистики, который вы можете чистить регулярно а не каждый запрос.
я уверен придумать места где будет экономия можно еще — это только основные.
а вообще на основе этой штуки фактически создается событийная машина полноценная, с циклами состояний (например агрегаторы фидов рекламных где запросы очень долгие к сторонним серверам делаются влет), а на основе PHP-FPM вы этого не сделаете именно из за ежекратного перезапуска
Локальный стек статистики, который вы можете чистить регулярно а не каждый запрос.
Да ну? Получается несколько стёков — для каждого воркера — СВОЙ.
Те же яйца, только в профиль.
Да и вообще. Я несколько лет угробил на демонов написанных на ПХП. Правда задачи были немного другие.
Так вот. Готовьтесь к граблям: 1) утечки памяти. 2) скрипт начинает жрать слишком много проц. времени 3) коннект с бд пропадает после нескольких минут не активности.
Мы тут все надеемся на GC в 5.3 :) Хотя да, проблема имеет место быть и с этим неизвестно как бороться
Воркеры, обычно, перезапускаются после N отработанных запросов. Изменяя это N можно избавиться от этой проблемы.
1) Прямые руки, GC, перезапуск.
2) Может это из-за кривых рук? В данном проекте ничего подобного нет.
3) Вообще-то это настраивается и делается, например, mysql_ping(). Если все-таки порвался его надо восстановить.
2) Может это из-за кривых рук? В данном проекте ничего подобного нет.
3) Вообще-то это настраивается и делается, например, mysql_ping(). Если все-таки порвался его надо восстановить.
1) Прямые руки, GC, перезапуск.
Нууу, тогда для людей, которым вы советуете попробовать ваше «умное» решение для публичных CMS, советуйте сразу выставлять количество проходов цикла, после которого осуществляется перезагрузка в еденицу.
2) Может это из-за кривых рук? В данном проекте ничего подобного нет.
Писался демон для отдачи статики. После нескольких суток отдачи больших по размеру файлов (в пике было около 900 одновременных потоков), демон начинал дёргаться как угорелый и сжирал 80% проц. времени. Я так и не нашёл в чём была эта проблема.
Замечу — что утечек в том скриптике не было вообще.
Вообще-то это настраивается и делается, например, mysql_ping(). Если все-таки порвался его надо восстановить.
Это я знаю. Я просто указал на грабли.
Нууу, тогда для людей, которым вы советуете попробовать ваше «умное» решение для публичных CMS, советуйте сразу выставлять количество проходов цикла, после которого осуществляется перезагрузка в еденицу.
2) Может это из-за кривых рук? В данном проекте ничего подобного нет.
Писался демон для отдачи статики. После нескольких суток отдачи больших по размеру файлов (в пике было около 900 одновременных потоков), демон начинал дёргаться как угорелый и сжирал 80% проц. времени. Я так и не нашёл в чём была эта проблема.
Замечу — что утечек в том скриптике не было вообще.
Вообще-то это настраивается и делается, например, mysql_ping(). Если все-таки порвался его надо восстановить.
Это я знаю. Я просто указал на грабли.
смотрите сама возможность создания стека становится возможной благодаря тому только что есть непрерывно работающий воркер который в конце работы не должен скидывать статистку.
PS. Вы (Nascosto) для себя как я уже вижу все решили и не слушаете аргументы других людей, поэтому не вижу необходимости вас в чем либо убеждать далее. Если вам выпадет удачный случай сделать что либо действительно высоконагруженное, то вы оцените все преимущества, а так для вас это все очевидно чужое и не понятное.
PS. Вы (Nascosto) для себя как я уже вижу все решили и не слушаете аргументы других людей, поэтому не вижу необходимости вас в чем либо убеждать далее. Если вам выпадет удачный случай сделать что либо действительно высоконагруженное, то вы оцените все преимущества, а так для вас это все очевидно чужое и не понятное.
PS. Вы (Nascosto) для себя как я уже вижу все решили и не слушаете аргументы других людей, поэтому не вижу необходимости вас в чем либо убеждать далее. Если вам выпадет удачный случай сделать что либо действительно высоконагруженное, то вы оцените все преимущества, а так для вас это все очевидно чужое и не понятное.
Вы знаете, я ни чего ещё не решил. Но решу сегодня. Когда погоняю утилиту AB сам. Поскольку мусье разработчик до сих пор не сумел ответить на данный вопрос. А вы — можете продолжать минусовать в компании с этим мусье :)
Вы знаете, я ни чего ещё не решил. Но решу сегодня. Когда погоняю утилиту AB сам. Поскольку мусье разработчик до сих пор не сумел ответить на данный вопрос. А вы — можете продолжать минусовать в компании с этим мусье :)
Вообще-то, Opcode-кеш (например, eAccelerator) кеширует лишь результат преобразования исходника в Opcode'ы движка Zend Engine. Всё равно инициализация классов, объектов, и всего прочего будет занимать прилично процессорного времени.
Более того, если посмотреть исходники eAccelerator, то видно, что он, фактически, сериализует опкод в некоторое свое потоковое представление (которое может еще и gzip-ом жать зачем-то, если его попросить), а при запуске скрипта — обратно распаковывает из сериализации во внутренние PHP-структуры. Вот на эту распаковку и тратится куча времени. Так что кэширование там не очень честное (хотя и дает большой прирост, особенно если все файлы склеить в один — почему, пока непонятно).
так теперь все в свои хуки СВН будут писать не только выгрузку файлов но и реинициализацию воркеров =)
А смысл? Поддерживается автоматическое обновление по mtime ;-)
а ну вот уже пошли фичи, чтож давай стабильную версию скорее и будем тестить ее повесив на *nginx на каком нибудь слабеньком VDS и посмотрим результаты
А Вы порадовали меня не меньше :-) Ведь для человека необходимо знать что плоды его работы востребованы, это чуть ли ни самое важное.
Буду ждать отзыв по использованию :-)
Буду ждать отзыв по использованию :-)
Я бы не хотел этого, с подозрением отношусь к чужому коду, тем более времени у меня хватает на единоличную разработку. Если будет принято решение о вводе в состав разработчиков еще кого-нибудь — внесу в свойствах проекта.
Патчи можно мне присылать на мыло и в список проблем на страничке проекта.
P.S. В единственном числе =)
Патчи можно мне присылать на мыло и в список проблем на страничке проекта.
P.S. В единственном числе =)
Макс, а я тебе давно говорил что будет FastCGI на ПоХаПе, правда я ожидал что это сделает другой человек :).
«Так можно сделать только в простейшем случае, когда используется одна-единственная копия приложения.
Если же мы хотим иметь множество копий приложения на разных серверах (а об этом пойдет речь в продолжении статьи), то нам в любом случае понадобится веб-сервер, который будет разруливать запросы по приложениям.»
© ivanych — habrahabr.ru/blogs/php/64938/#comment_1812364
Если же мы хотим иметь множество копий приложения на разных серверах (а об этом пойдет речь в продолжении статьи), то нам в любом случае понадобится веб-сервер, который будет разруливать запросы по приложениям.»
© ivanych — habrahabr.ru/blogs/php/64938/#comment_1812364
Враки. Можно повесить round-robin DNS или вообще BGP заюзать.
Ну можно вообще всё на асме написать = )
В обработке HTTP не так давно apache имел проблемы — chunked формат не разбирал правильно, а сколько над апачем работали. PHP будет иметь не меньше проблем. Кроме того, надо будет сделать разбор .htaccess — ведь именно он держит от перехода на nginx, значит нужен. Надо убедиться что PHP умеет выполнять больше одного запроса, написать для него тот же набор модулей что сейчас есть для апача. Работы — море, а даже сейчас производительность обработки запросов упирается не в процессор, так что есть ли смысл?
HTTP — это один из уровней, а деление на уровни добавляет надёжности и гибкости.
HTTP — это один из уровней, а деление на уровни добавляет надёжности и гибкости.
Хороший вопрос. С удовольствием отвечу развернуто.
Сервера приложений в подавляющим большинстве случаев синхронны (грубо говоря не могут обрабатывать второй запрос пока полностью не завершен первый), а хорошие веб-сервера — асинхронны (nginx, lighttpd).
Таким образом, если встроить HTTP-сервер в сервер приложения, то я начну скачивать ответ по 1 байту в секунду и 3 мегабайта памяти сервера будут ждать пока я не отключусь или не получу всё что мне причитается! Такую систему будет очень легко за-DoS'ить, и производительностью она не отличается.
В случае с nginx + FastCGI мы сразу же завершаем запрос (сетевой overhead будет лишь в виде очень быстрой доставки данных до nginx), а nginx в свою очередь может отдавать по 1 байту в минуту без какой-либо потери производительности (он тратит на висящий коннект всего несколько байт оперативной памяти). Ну и keep-alive коннекты pool'ить на PHP не с руки…
Сервера приложений в подавляющим большинстве случаев синхронны (грубо говоря не могут обрабатывать второй запрос пока полностью не завершен первый), а хорошие веб-сервера — асинхронны (nginx, lighttpd).
Таким образом, если встроить HTTP-сервер в сервер приложения, то я начну скачивать ответ по 1 байту в секунду и 3 мегабайта памяти сервера будут ждать пока я не отключусь или не получу всё что мне причитается! Такую систему будет очень легко за-DoS'ить, и производительностью она не отличается.
В случае с nginx + FastCGI мы сразу же завершаем запрос (сетевой overhead будет лишь в виде очень быстрой доставки данных до nginx), а nginx в свою очередь может отдавать по 1 байту в минуту без какой-либо потери производительности (он тратит на висящий коннект всего несколько байт оперативной памяти). Ну и keep-alive коннекты pool'ить на PHP не с руки…
Так в том и суть, чтобы сделать http сервер с мультиплексором. И тут не принципиально http ли это, или FastCGI протокол. Ну возможно бинарная сущность второго, какой-то выигрыш и даст, но зато у первого больше выбор middleware и тулзов вокруг.
Там и нет преобразований, веб-серверу даже проще работать с FastCGI.
Особенности протокола дают преимущество. В протоколе есть пакетные потоки STDIN и STDOUT, передаваемые данные инкапсулируются в структуру Record, и из заголовка пакета мы всегда знаем его длину. Между тем, HTTP поточный протокол, без инкапсуляции в пакеты по умолчанию — там это реализовано через chunked encoding, и ничего хорошего это в себе не несет.
Особенности протокола дают преимущество. В протоколе есть пакетные потоки STDIN и STDOUT, передаваемые данные инкапсулируются в структуру Record, и из заголовка пакета мы всегда знаем его длину. Между тем, HTTP поточный протокол, без инкапсуляции в пакеты по умолчанию — там это реализовано через chunked encoding, и ничего хорошего это в себе не несет.
круто. видел подобный проект, только реализовывался SCGI (который попроще). но там как-то не уживались (как минимум, у меня) несколько воркеров, только один — и вся затея теряла смысл.
из беглого чтения кода я так понял, что делаем неблокируемый сокет, форкаем детей, а дальше какой ребёнок первым поймает коннект, тот его и обслуживает. правильно?
из беглого чтения кода я так понял, что делаем неблокируемый сокет, форкаем детей, а дальше какой ребёнок первым поймает коннект, тот его и обслуживает. правильно?
Ох уж эти гитовцы… GitHub != DVCS ;)
Дубль 2: git != github
на gitorious.org ;)
На то, что отождествлять инструмент и хостинг для него — фанатичное ламерство, ничего личного
Зачем github? Google Code поддерживает Mercurial и уходить никуда не надо %)
на самом деле реализация это штуки есть давно (вкупе с фтп-сервером), есть и у меня в фремворке но для задач отладки приложения исключительно (запускается в консоли сервер и можно попробовать корректность установки приложения до установки нормального сервера — полный аналог webrick) причина банальна, когда в этом работает мощный фреймворк появляется проблема циклических ссылок вернее их неудаляемости, использование памяти растет ооочень быстро, очень быстро появляются сегфолты (к сожалению опять-же природа любимого пыха когда резко растет число ссылок в памяти), я для себя в частном случае очень бережно слежу за контролем ссылок с своем фреймворке но на сколько знаю этого никто больше не делает по причине не надобности.
советую сразу ориентироваться на php 5.3 и на его gc (хотя скорость упадет существенно).
также подтверждаю — скорость обработки запросов получается очень большой, в моем случае 100 кратный прирост на 10 конкурентных потоках ab при использовании eaccelerator/.
П.С. а как вы контролируете «живость» воркеров? я ничего умнее pid-файлов не нашел но это не надежно в данном случае (смерть по сегфолту мгновенная и безоговорочная ;)) и медленно
советую сразу ориентироваться на php 5.3 и на его gc (хотя скорость упадет существенно).
также подтверждаю — скорость обработки запросов получается очень большой, в моем случае 100 кратный прирост на 10 конкурентных потоках ab при использовании eaccelerator/.
П.С. а как вы контролируете «живость» воркеров? я ничего умнее pid-файлов не нашел но это не надежно в данном случае (смерть по сегфолту мгновенная и безоговорочная ;)) и медленно
Контролирую сигналами, разумеется.
В PHP5 можно контролировать и без GC, но нужно писать объектно — что бы деструкторы чистили всё лишнее и делать уничтожение данных приложения — т.е. практически как на C++ писать получить — проинициализировал динамически что-то — не забудь потом убить. Не смотря на то, что у меня нету такого зверства — я именно так и поступаю — чищу после себя всё, прописываю везде деструкторы. Помогает :)
А вообще для highload'ов пригодится — я скорее всего это заюзаю даже — есть где :)
А вообще для highload'ов пригодится — я скорее всего это заюзаю даже — есть где :)
скажите, это можно будет использовать для уже готовых проектов и каких-нибудь CMS (Drupal например — он ужасно много жрет при инициализации), может с минимальными переделками, или тут надо с нуля всё по-новой писать?
Тема конечно интересная, но не верю я в стабильность демонов на пхп. Если ребята не забросят проект — обязательно использую стабильную версию, но до неё ещё ой как далеко. Одно дело тестовый процесс живущий час другой, а другое дело высоконагруженный сервер с кучей запросов и необходимостью железного аптайма. Одним словом удачи!
Кстати вопрос насчет количества запрсоов в секунду. Можете привести параметры запуска ab?
Ну и конфигурацию железки тоже интересно бы глянуть.
Ну и конфигурацию железки тоже интересно бы глянуть.
С php 5.2.10: Fatal error: Call to undefined function pcntl_sigtimedwait() in /usr/local/etc/phpfastcgi/thread.class.php on line 98 :(
Только с PHP 5.3.0 работает что ли? :(
Только с PHP 5.3.0 работает что ли? :(
Прошу прощенья, дописал требования в статью. Вам необходимо собрать PHP с параметрами '--enable-pcntl' '--enable-shmop' '--enable-sockets'.
Работать будет на всех версиях пятой ветки PHP (даже на 5.1 пробовал).
Работать будет на всех версиях пятой ветки PHP (даже на 5.1 пробовал).
все эти модули стоят, однако ошибку все равно выдает.
в справке пхп написано что функция pcntl_sigtimedwait доступна начиная с версии 5.3 вроде
в справке пхп написано что функция pcntl_sigtimedwait доступна начиная с версии 5.3 вроде
можно взять модуль pcntl из 5.3, засунуть его в 5.2.10 и пересобрать php (или сделать phpize и собрать отдельно pcntl).
изменения в коде модуля pcntl между 5.2 и 5.3 небольшие, так что проблем это вызвать не должно.
изменения в коде модуля pcntl между 5.2 и 5.3 небольшие, так что проблем это вызвать не должно.
в теме много «разных» комментариев, автор можно в материал добавить «маркетинговую» таблицу сравнение (для общего развития):
сравнение разного рода вариантов и реализаций таких как spawncgi (был в lighttpd), PHP-FPM, etc…
сравнение разного рода вариантов и реализаций таких как spawncgi (был в lighttpd), PHP-FPM, etc…
Отлично, наконец-то у нас появилась возможность тратить время на поиск memory leaks )
Кстати, раскрою карты. У меня в планах реализация shared object'ов в разделяемой памяти =) Worker'ы смогут общаться между собой и делиться полезными данными, таким образом, например, обновление блока статистики на сайте (выборка из memcached) будет происходить к примеру не чаще раза в 5 секунд, первым воркером который решил это сделать.
Для программиста это будет прозрачно и таких слов как shared memory и семафоры знать ему не потребуется :-)
Для программиста это будет прозрачно и таких слов как shared memory и семафоры знать ему не потребуется :-)
Круто, конечно же, но рановато, так как в PHP ещё не до конца допилили сборщик мусора, который не слишком приспособлен к долгоиграющим приложениям. Также хотелось бы получить многопоточность, которая пока что возможна только используя mpm_worker + mod_php.
А так ли нужна многопоточность? Думаю, важнее неблокируемость, а она на совести программиста.
в пхп по определению невозможно создать многопоточность.
mpm_worker может создать многопоточность. Да, php об этой многопоточности ничего не известно, но достоинства от многопоточности всё равно видны: уменьшенное потребление памяти. Почему бы тогда и fastcgi этого не сделать? )
mpm — это механизм апача, вместо пре-форк использовать треды
к многопоточности пхп отношения не имеет
каждый поток запущенный с пхп жрет минимум 44метра и использование тредов производительность не на много увеличивают
лучший выход — вообще отказаться от апача
я не вижу как это принципиально возможно применить к фцги
мы можем префоркаом или по требованию народить необходимое кол-во процессов и не более. но мы не сможем создать тредовую многопоточность в принципе, иначе — меняйте язык.
к многопоточности пхп отношения не имеет
каждый поток запущенный с пхп жрет минимум 44метра и использование тредов производительность не на много увеличивают
лучший выход — вообще отказаться от апача
я не вижу как это принципиально возможно применить к фцги
мы можем префоркаом или по требованию народить необходимое кол-во процессов и не более. но мы не сможем создать тредовую многопоточность в принципе, иначе — меняйте язык.
>Почему бы тогда и fastcgi этого не сделать?
средствами пхп это сделать невозможно. ее нет по определению в пхп.
оборотная сторона многопоточности — это в случае креша одной нити — крешится все приложение. По этому в целях надежности выбирают схемы, где запускаются отдельные процессы.
средствами пхп это сделать невозможно. ее нет по определению в пхп.
оборотная сторона многопоточности — это в случае креша одной нити — крешится все приложение. По этому в целях надежности выбирают схемы, где запускаются отдельные процессы.
>phpFastCGI — правильная реализация FastCGI, которая позволяет добиться немыслимой производительности.
всякое подобное утверждение должно подкрепляться цифрами и фактами
кроме голословных утверждений с статье ничего нет.
всякое подобное утверждение должно подкрепляться цифрами и фактами
кроме голословных утверждений с статье ничего нет.
Все умерло? :-)
Обнаружил code.google.com/p/phpdaemon/
PHPFastCGI превратился в phpDaemon (см. коммент выше).
Некоторая информация о попытке применения этого добра — javascript.ru/blog/Ilya-Kantor/True-FastCGI-dlya-PHP-migraciya-testy
Некоторая информация о попытке применения этого добра — javascript.ru/blog/Ilya-Kantor/True-FastCGI-dlya-PHP-migraciya-testy
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
phpFastCGI: настоящий FastCGI для PHP