Появилась задача - прием и обработка большого массива данных.
Сейчас реализовано через связку nginx+phpfpm+rabbitmq. Объем поступающих данных довольно большой(~ 40 000 req/min). Состоит из двух частей - первый - принимает, делает простейшую валидацию данных и отправляет в rabbitmq. Вторая часть - бэкграунд скрипт, разбирающий очередь и обрабатывающий как надо.
Затык происходит на 1 этапе. "Иногда" немного стопорится phpfpm, из за высокой частоты запросов, все воркеры получаются занятыми - часть данных теряется.
Есть идея переписать первую часть на node.js, но плодить различные технологии не хочется, да и в свете выхода Php7 - ReactPHP кажется очень перспективным направлением.
Протестировали его(ReactPHP в связке с nginx в виде балансировщика), сделали небольшие нагрузочные тесты и он "вроде бы" выдерживает х10-15 раз запросов.
Есть у кого опыт успешного внедрения ReactPHP в проект? Есть известные подводные камни?
1) Стоит ли использовать php-pm? Я больше смотрел на демонизацию с помощью supervisord, просто потому, что давно его использую и больше ему доверяю.
2) Как поступать с расширениями? Есть например переписанные php-redis под неблокирующие вызовы, но на "чистом php". Действительно ли лучше его использовать, а не расширения? Больше конкретно Rabbit\Mongdo интересуют конечноже.
yiicoder: ну у меня реакт используется не по собственной прихоти, а потому что так решил разработчик который изначально был на проекте и потом свалил. В целом там было очень много архитектурных промашек и еще и монга в качестве основной базы (что хуже чем писать демоны на php, хотя бывают исключения).
1) php-pm - вполне себе норм. Единственное что я бы не стал ему доверять на 100% и мастер процесс всеравно бы еще для надежности под контроль супервизора поместил. Я уже давно хочу чуть чуть попдравить его что бы мастер процесс занимался только управлением процессами, а хэндлинг запросов тогда можно было бы спокойно вынести в отдельные воркеры и распаралелить, тогда риски сократились бы а профита было бы еще больше (скажем разбор multipart запросов вынести в отдельные воркеры что бы не лочить обработку запросов). В целом же довольно неплохой способ повысить RPS.
2) То что экстеншен для монги на чистом PHP особо разницы не должно давать - PHP работает быстро, а большая часть времени работы - межпроцессорное взаимодействие через сокеты, все же основное там всеравно написано на Си (сокеты, селекты и т.д.)
php - stateless язык. Демоны на php безусловно можно писать, но это не его целевое применение.
Этап 1 ReactPHP не спасет. Увеличивайте количество воркеров nginx/fpm.
PHP7 станет по настоящему production ready только через года 2, если не более. Дело тут как в ошибках самого php, так и в зависимостях, которые вы используете, они должны поддерживать 7-ку в полной мере. Например $this->$some[$thing] меняет логику выполнения в 7-ке, последствия - не предсказуемы.
Посему я бы на вашем месте писал эту часть на ноде, предварительно увеличив количество процессов libuv. А в случае нехватки - поднимал множество процессов с балансировкой через nginx.
В каких ошибках PHP? Домыслы, не более. Огромное количество тестов как в самом PHP, так и в фреймворках/библиотеках очень быстро поймают/уже поймали практически всё, с чем вы можете столкнуться.
Есть некоторые несовместимости, но:
1) Это практически всегда пограничные случаи
2) Все современные фреймворки и библиотеки уже сегодня тестируются на совместимость с PHP7
> предварительно увеличив количество процессов libuv
И получите ReactPHP, только на JavaScript, LOL, возвращаемся к исходному вопросу)
> В каких ошибках PHP? Домыслы, не более.
Конечно домыслы, php.net/ChangeLog-5.php#5.5.27 (27-мая минорная версия) Тексты в стиле "Fixed bug" - это чисто мое воображение и их не существует. 7-ка еще даже не вышла, но учитывая, что API расширений было изменено - как следствие ошибки перехода будут возникать в любом случае.
> Все современные фреймворки и библиотеки уже сегодня тестируются на совместимость с PHP7
Смотрел только что:
index0h: почему топором то? В PHP корутины скажем можно уже сейчас писать, в node.js только с трансляцией. Это я как пример. В общем и целом и там и там event-loop, и там и там libuv/libev можно юзать (и react это подхватит). У меня есть опыт работы так же и с PHP-PM, и там риски вообще минимальны - чисто управление процессами сделано в виде демона, в воркерах же просто бутстрапится фреймворк и сбрасывается после каждого запроса, то есть нагрузка на сервер в принципе такая же, RPS можно нехило поднять.
Почему не посмотрите на HHVM? Код переписывать не нужно, после некоторого количества запросов HHVM компилирует критические участки в машинный код и таким образом ускоряется ещё больше (изначально запросы скорее всего будут медленнее отрабатывать).
К стати, можно с HHVM запускать ReactPHP.
И ещё, ReactPHP всё ещё не умеет multipart запросы, если реализуете - отправьте pull request
Ну PR как бы есть, и он вроде бы местами адекватный, хотя надо тестить. Я просто заводил отдельный процесс воркер и там парсил запросы, тогда можно использовать ворах готовых библиотек для разбора мультипарт запросов и в принципе выплевывать назад нормальный запрос, и скейлить это удобно.
Пробовали. PHP5.6 уже очень близок по скорости в HHVM. Производительность поднимается в лучшем случае в 2-3 раза, но при этом получаем большое количество проблем с расширениями.
например тотже RabbitMQ. Там есть библиотека, которая написана на "чистом" php, так вот просто php5.6+сишное расширение уделывает на раз HHVM.
yiicoder: Близок? Простите, что???
Посмотрите статью более чем месячной давности: hhvm.com/blog/9293/lockdown-results-and-hhvm-perfo...
Я практически уверен, что большинство написанного на PHP для HHVM не составит никаких проблем по сравнению с нативным расширением, потому что HHVM работает иначе и применяет другие оптимизации.
Назар Мокринский: JIT-технологии очень такие.. на некоторых синтетических тестах Java работает быстрее C++ ) Так и здесь. На реальных приложениях все выглядит сильно приземленней.
Наше приложение крайне простое - принять json данные с сервера, сделать простейшую валидацию(распарсить, проверить пару параметров) и отправить в RabbitMQ. Вот на этом процессе HHVM не давал существенного преимущества.. т.е. х2х3 может быть. По тестам ReactPHP дает х10 прирост.
Да, можно ReactPHP запускать под HHVM - это исследование будет обязательно проведено, когда станет ясно, что это годная технология вообще.
Почему вот просто так взять и не написать нативный сетевой демон на C? 