-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Демон для обработки очереди
- Автор темы grigori
- Дата начала
интересный https://github.com/nrk/predis-async/ - но он как-раз сырой и заброшенный
У меня этот predis-async работает в reactphp-проекте без каких-либо нареканий вообще. Как года три назад код написал, так и крутится, все стабильно, процесс не пухнет (я, правда, по таймеру gc дергаю), рестартуется только при ребуте сервера.
Но я, конечно, оттестированную версию в composer.lock зафиксировал. Может, с тех пор и наломали чего.
Но я, конечно, оттестированную версию в composer.lock зафиксировал. Может, с тех пор и наломали чего.
смотрите что товарищи выворяют: https://github.com/swoole/swoole-src - корутины, каналы, потоки, асинк, и свежее!
https://pecl.php.net/package/swoole
https://pecl.php.net/package/swoole
Последнее редактирование:
Кстати, https://wiki.php.net/rfc/fiber
корутины, каналы, потоки, асинк, и документация на китайском! Собственно, это меня и остановило.
сайт на кетайском, а api на английском https://github.com/swoole/swoole-docs/blob/master/modules/swoole-server/methods/construct.md
а самая звездно-полосатая корпорация вместо того, чтобы сделать что-то полезное, нашла в php фатальный недостаток, и сделала такое же, только другое
а самая звездно-полосатая корпорация вместо того, чтобы сделать что-то полезное, нашла в php фатальный недостаток, и сделала такое же, только другое
Последнее редактирование:
ES20xx/Typescript, 1 в 1
только без постгреса, редса, файловых операций
а у китайцев сделай канал, оберни в корутину, и работай, еще бы динамически вытесняло блокирующие вызовы в потоки - и тот же golang
написано, что блокирующие вызовы можно вынести в Task Worker - но как это работает, я еще не проверял
кроме того, в отличие от hhvm, у них искаропки реализован асинк для файлов, постгреса, редиса, websocket/dns/http/tcp/udp - ситуаций, когда надо делать синхронный вызов, немного
ресайз картинок, шифрование - судя по написанному, с этим оно справится
@флоппик, https://www.swoole.co.uk/
Асинк для файлов в линуксе работает очень условно, можно сказать, что вовсе не работает (при aio не используется fs cache, в итоге получается еще хуже) - поэтому в nginx и сделан тредпул.
В freebsd с этим все хорошо, но кому она нужна
И не факт, что будет профит от реализации на С. Вот такие коллбэки, с вызовами PHP-шных callables из extensions, в PHP очень медленные, я это еще по Blitz templates помню.
В freebsd с этим все хорошо, но кому она нужна
То есть не треды, а процессы? Так в php сработает, но много возни с синхронизацией через shared memory (можно и иначе, но через shared memory производительнее всего). Не факт, что они так заморочились (хотя надо смотреть). А без нее может получиться весело с конкуретным доступом.
Ну то есть опять же самодельная реализация протоколов, как и в случае с ReactPHP.
И не факт, что будет профит от реализации на С. Вот такие коллбэки, с вызовами PHP-шных callables из extensions, в PHP очень медленные, я это еще по Blitz templates помню.
Последнее редактирование:
@fixxxer, как сделаны worker process - потоками или процессами, не написано, надо собрать и посмотреть
каналы реализованы через shared memory, таки заморочились
с колбеками - да, помню ту историю, и про асинк в июне подробно Бартенева слушал, но тут вопрос: с чем сравниваем, и для каких операций?
* на php storage не пишут
* если это обработчик бизнес-логики или асинхронный клиент-сервер, то вся наша запись - это логи
* если сравнивать swoole и react - то с eio в реакте точно такие же колбеки
* а если с нодой - там точно такие же worker threads
каналы реализованы через shared memory, таки заморочились
с колбеками - да, помню ту историю, и про асинк в июне подробно Бартенева слушал, но тут вопрос: с чем сравниваем, и для каких операций?
* на php storage не пишут
* если это обработчик бизнес-логики или асинхронный клиент-сервер, то вся наша запись - это логи
* если сравнивать swoole и react - то с eio в реакте точно такие же колбеки
* а если с нодой - там точно такие же worker threads
Последнее редактирование:
@grigori, с reactphp в том смысле, что колбэки те же самые, и есть подозрение, что на них большая часть производительности и теряется, и от реализации протоколов в сишном расширении профит получится в пределах погрешности измерений; зато php-шный код я хоть отдебажить смогу, если что, с расширением все сложнее. А с нодой в том смысле, что там такой проблемы с колбэками нет. Что касается async disk i/o, я не думаю, что это прям нужно в php (или node), вот даже задачи такие в голову не приходят, просто к слову.
про дебаг я думаю то же самое - выигрыша меньше, чем проблем в будущем, особенно если кетайцы забьют на эту поделку, как на yii
а если без асинхронных файловых операций - фотки, архивы, бекапы надо в отдельный сервис выносить на fpm, получается
а если без асинхронных файловых операций - фотки, архивы, бекапы надо в отдельный сервис выносить на fpm, получается
Последнее редактирование:
Отдельными микросервисами, да, самое то. Я обычно всякую такую обработку через очередь делаю, чтобы пиковых нагрузок не было и не возиться с обработкой ошибок в момент вызова.
и вернулись к вопросу где очередь - fpm при всем желании сам из очереди задачи не выгребет, ни из редиса, ниоткуда, нужен дирижер, асинхронный, который отловит событие и, как писал Флоппик, откроет соединение с fpm