Демон для обработки очереди

fixxxer

К.О.
Партнер клуба
@grigori, с производительностью php7 расширения особо не нужны. predis/predis написан на чистом php и работает зачастую даже быстрее расширений (за счет отсутствия копирований из сишных структур в zval-ы и обратно).
 

fixxxer

К.О.
Партнер клуба
У меня этот predis-async работает в reactphp-проекте без каких-либо нареканий вообще. Как года три назад код написал, так и крутится, все стабильно, процесс не пухнет (я, правда, по таймеру gc дергаю), рестартуется только при ребуте сервера.

Но я, конечно, оттестированную версию в composer.lock зафиксировал. Может, с тех пор и наломали чего.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
понял, спасибо
там последние правки кода 3 года назад
 

флоппик

promotor fidei
Команда форума
Партнер клуба

grigori

( ͡° ͜ʖ ͡°)
Команда форума
сайт на кетайском, а api на английском https://github.com/swoole/swoole-docs/blob/master/modules/swoole-server/methods/construct.md

а самая звездно-полосатая корпорация вместо того, чтобы сделать что-то полезное, нашла в php фатальный недостаток, и сделала такое же, только другое
Fortunately, HHVM provides an async version of curl_exec()
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
и заблокируйся на первом же вызове.
написано, что блокирующие вызовы можно вынести в Task Worker - но как это работает, я еще не проверял
кроме того, в отличие от hhvm, у них искаропки реализован асинк для файлов, постгреса, редиса, websocket/dns/http/tcp/udp - ситуаций, когда надо делать синхронный вызов, немного
ресайз картинок, шифрование - судя по написанному, с этим оно справится

@флоппик, https://www.swoole.co.uk/
 

fixxxer

К.О.
Партнер клуба
Асинк для файлов в линуксе работает очень условно, можно сказать, что вовсе не работает (при aio не используется fs cache, в итоге получается еще хуже) - поэтому в nginx и сделан тредпул.

В freebsd с этим все хорошо, но кому она нужна :)
написано, что блокирующие вызовы можно вынести в Task Worker
То есть не треды, а процессы? Так в php сработает, но много возни с синхронизацией через shared memory (можно и иначе, но через shared memory производительнее всего). Не факт, что они так заморочились (хотя надо смотреть). А без нее может получиться весело с конкуретным доступом.

постгреса, редиса, websocket/dns/http
Ну то есть опять же самодельная реализация протоколов, как и в случае с ReactPHP. :)
И не факт, что будет профит от реализации на С. Вот такие коллбэки, с вызовами PHP-шных callables из extensions, в PHP очень медленные, я это еще по Blitz templates помню.
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@fixxxer, как сделаны worker process - потоками или процессами, не написано, надо собрать и посмотреть
каналы реализованы через shared memory, таки заморочились

с колбеками - да, помню ту историю, и про асинк в июне подробно Бартенева слушал, но тут вопрос: с чем сравниваем, и для каких операций?
* на php storage не пишут
* если это обработчик бизнес-логики или асинхронный клиент-сервер, то вся наша запись - это логи
* если сравнивать swoole и react - то с eio в реакте точно такие же колбеки
* а если с нодой - там точно такие же worker threads
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
@grigori, с reactphp в том смысле, что колбэки те же самые, и есть подозрение, что на них большая часть производительности и теряется, и от реализации протоколов в сишном расширении профит получится в пределах погрешности измерений; зато php-шный код я хоть отдебажить смогу, если что, с расширением все сложнее. А с нодой в том смысле, что там такой проблемы с колбэками нет. Что касается async disk i/o, я не думаю, что это прям нужно в php (или node), вот даже задачи такие в голову не приходят, просто к слову.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
про дебаг я думаю то же самое - выигрыша меньше, чем проблем в будущем, особенно если кетайцы забьют на эту поделку, как на yii

а если без асинхронных файловых операций - фотки, архивы, бекапы надо в отдельный сервис выносить на fpm, получается
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Отдельными микросервисами, да, самое то. Я обычно всякую такую обработку через очередь делаю, чтобы пиковых нагрузок не было и не возиться с обработкой ошибок в момент вызова.
и вернулись к вопросу где очередь - fpm при всем желании сам из очереди задачи не выгребет, ни из редиса, ниоткуда, нужен дирижер, асинхронный, который отловит событие и, как писал Флоппик, откроет соединение с fpm
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
тогда демон должен уметь дирижировать fpm-процессами, то есть, обрабатывать ситуацию, когда все воркеры заняты и когда они не работают
 
Сверху