Ожидал всё-таки услышать больше информацию. Это всё и так доступно на каждом бложике. А вот такие вопросы как работать с асинхронностью, очепередями, какие подводные камни и реальный опыт использования это интересно.
Небольшое, но важное дополнение - можно использовать XDebug в связке Octane + Swoole. Для отладки необходимо использовать метод xdebug_break(). За подсказку спасибо Владимиру)
Вопрос - в момент перезапуска октана будет момент, когда приложение не работает и если в этот момент придут запросы, то будет ошибка - как делать деплой без простоя?
Тут придётся использовать механизм, который будет направлять трафик на "старую" версию приложения, пока "новая" версия не запустится и только после этого перенаправлять трафик на "новую" версию.
@@indigoram89 Как вариант, можно использовать Kubernetes, который позволяет делать развёртывание обновлений без простоя, балансируя нагрузку между старыми и новыми версиями приложения
Хороший вопрос! В данном случае есть две разные ситуации - обслуживание очереди и запуск artisan-команд по расписанию. Для первого случая, в котором участвуют очереди, нет необходимости в Octane, т.к. команда queue:work работает по тому же принципу - стартует фреймворк и обрабатывает очередь. Остановить её можно либо вручную, либо если возникнет исключение. Для второго случая, выполнение запланированных задач, он не поможет, т.к. Octane специализируется на обслуживании запросов. Но можно провести эксперимент)
У нас, на проектах, где используется GraphQL(пакет от Rebing), без октана приложение стартует в среднем 150мс, тяжелый запрос отрабатывает 50мс. В целом выходит ~200mc. С октаном, он же, 60мс. Профит тем выше от октана, чем больше маршрутов и провайдеров загружается при буте приложения. + Можно было рассказать про фичи реализованные при использовании swoole. Например про ускорение за счет concurrently запросов(в бд например).
Ожидал всё-таки услышать больше информацию. Это всё и так доступно на каждом бложике. А вот такие вопросы как работать с асинхронностью, очепередями, какие подводные камни и реальный опыт использования это интересно.
Вопрос отправляется в копилочку на следующий митап, спасибо!
Небольшое, но важное дополнение - можно использовать XDebug в связке Octane + Swoole. Для отладки необходимо использовать метод xdebug_break(). За подсказку спасибо Владимиру)
Вопрос - в момент перезапуска октана будет момент, когда приложение не работает и если в этот момент придут запросы, то будет ошибка - как делать деплой без простоя?
Тут придётся использовать механизм, который будет направлять трафик на "старую" версию приложения, пока "новая" версия не запустится и только после этого перенаправлять трафик на "новую" версию.
@@sergeysaharov5750 а как это сделать если сервер один и там порт уже занят старой версией? новый экземпляр octane на запустится, пока старый работает
@@indigoram89 Как вариант, можно использовать Kubernetes, который позволяет делать развёртывание обновлений без простоя, балансируя нагрузку между старыми и новыми версиями приложения
@@sergeysaharov5750 согласен, но не все его используют, а другие варианты есть? ))
@@indigoram89 Docker Swarm?)
Вопрос - нужно ли запускать октан на сервере очередей и на крон-сервере, выполняющем запланированые задачи?
Хороший вопрос! В данном случае есть две разные ситуации - обслуживание очереди и запуск artisan-команд по расписанию. Для первого случая, в котором участвуют очереди, нет необходимости в Octane, т.к. команда queue:work работает по тому же принципу - стартует фреймворк и обрабатывает очередь. Остановить её можно либо вручную, либо если возникнет исключение. Для второго случая, выполнение запланированных задач, он не поможет, т.к. Octane специализируется на обслуживании запросов. Но можно провести эксперимент)
@@sergeysaharov5750 спасибо! всё логично =)
Смотрел на x2, вы так ржете прикольно.
Главное на пробуй на 0,5))
На х2 весь доклад выглядит прикольно)
кстати, одна из основных проблем php это однопоточность, это вечно приходится обходить разными способами T_T
У нас, на проектах, где используется GraphQL(пакет от Rebing), без октана приложение стартует в среднем 150мс, тяжелый запрос отрабатывает 50мс. В целом выходит ~200mc. С октаном, он же, 60мс. Профит тем выше от октана, чем больше маршрутов и провайдеров загружается при буте приложения. + Можно было рассказать про фичи реализованные при использовании swoole. Например про ускорение за счет concurrently запросов(в бд например).
Хорошая идея, как-нибудь расскажем! 👀
Полностью с вами согласен, но детально осветить все фичи в одном докладе сложно, можно попросту не уложиться в лимит времени)