В ноябре тоже перенес свой проект на сервер приложений. Тестировал swoole, openswoole, roadrunner. В итоге остановился на swoole. В моем случае swoole и openswoole показали результаты лучше, чем roadrunner. Сравнивал я именно скорость ответа от бекэнда. Но стоит отметить, что и код свой я сильно не переписывал, а только избавился от синглтонов, статических методов и DI в методах контроллеров (DI теперь только в конструкторах). Но с чем я так и не разобрался, так это как дебажить )) Дебаг настроить я так и не смог ) Мне кажется это было бы отличной темой для видео. Информации по настройке отладки крайне мало.
@@roman_roman_roman_roman Замеры типа нагрузки на проц я не делал. Но точно могу сказать, что время ответа от бекенда уменьшилось в 2 раза. Это при том, что я не использовал Octane::concurrently. И у меня используется nginx как прокис + кеш статики.
Спасибо, интересо. Кстати, 500-ые при тестах fpm могли быть связаны с кончившимися воркерами, сколько их там было? Явно не 500. Также инетерсно что с памятью, греет душу что один бинарник асинхронно отвечающий на запросы должен есть меньше чем несколько отдельных процессов в виде воркеров fpm. Если память нормально чистится.
Очень интересная тема. Хотя пока железа хватает, что бы вытянуть мои приложения на php+laravel+nginx, постепенно увеличивается требования к железу за счет новых функций без которых никуда. По этому надо учить новые технологии. За видос Благодарю. Все понятно и без воды)
Привет! Ого, тему какую поднял!) А мне довелось перепробовать всё, включая Swoole, в боевых условиях. Не нужен тебе RR и Spiral, возьми лучше Swoole и HyperF) Я вот без шуток, получишь всё тоже самое, только быстрее в 5 раз, а ещё и Coroutine-optimized Eloquent ORM и много привычных из ларки вещей. У меня HyperF сейчас на бою (клиент-сервисы и микросервисы), несколько месяцев уже, работает быстро и стабильно. Держим нагрузочки так, что даже сервер не потеет. Как работает HyperF с рендером HTML - я, честно, не знаю, мне кажется когда речь заходит о таких вещах, обычно фронт уже отделён давным-давно и общается с бэком по REST, WebSocket и т.п.. Что же касается Octane - конечно на RR или Swoole ларка будет лучше себя чувствовать, но она, как по мне, избыточна перегружена сама по себе. Как монолит для небольших проектов с небольшой нагрузкой - ок, но что то серьёзнее, пу-пу-пу... P.s. для тех кто не в курсе, HyperF - это фреймворк который написан именно под Swoole, при этом сам Swoole это именно базовое PHP расширение написанное на C++. Во фреймворке реализована работа с БД (MySQL и PgSQL) на уровне самого расширения. Очень рекомендую затестить!!! Правда документация отвратительная, много чего не описано и не упомянуто, но есть всё, что нужно для работы, особенно если у вас микросервисы или вы планируете переход на такую архитектуру. Проект активно развивается, куда более популярен чем спиралька.
Привет! Спасибо за подробный комментарий! Честно говоря мне Swoole из за документации сразу не понравился и я на него пока не смотрел, но обязательно гляну и на HyperF тоже
Потому что есть готовые проекты куда легче всего интегрировать такие вот сервера приложения типа rr, Franken дабы увеличить скорость. а времени нет все переписывать. Поэтому лучше доучивать сам go как доп язык.
Геморроя больше чем пользы, время загрузки Фреймворка часто много меньше времени на остальную часть кода... Те кто это смотрит, никогда не будет использовать это в продакшине...
Я собеседовался и меня спросили про octane и roadranner . В той компании используют, и я в неё не попал. Думаю много кто перейдет, особенно крупные бизнесы.
В ноябре тоже перенес свой проект на сервер приложений. Тестировал swoole, openswoole, roadrunner. В итоге остановился на swoole. В моем случае swoole и openswoole показали результаты лучше, чем roadrunner. Сравнивал я именно скорость ответа от бекэнда. Но стоит отметить, что и код свой я сильно не переписывал, а только избавился от синглтонов, статических методов и DI в методах контроллеров (DI теперь только в конструкторах). Но с чем я так и не разобрался, так это как дебажить )) Дебаг настроить я так и не смог ) Мне кажется это было бы отличной темой для видео. Информации по настройке отладки крайне мало.
@@roman_roman_roman_roman Замеры типа нагрузки на проц я не делал. Но точно могу сказать, что время ответа от бекенда уменьшилось в 2 раза. Это при том, что я не использовал Octane::concurrently. И у меня используется nginx как прокис + кеш статики.
Брат, а Telescope не работает в данном случае?
Используй buggregator и symfony var dumper
Сделайте урок пуш уведомления
👌
++
❤❤
Огонь, спасибо!
🔥
Очень интересно, хотелось бы больше видео на данную тему
Сделаем
@@CutCodeRu ждём с нетерпением :)
++
++
Отличное видео, интересно подавали, спасибо
Спасибо, интересо.
Кстати, 500-ые при тестах fpm могли быть связаны с кончившимися воркерами, сколько их там было? Явно не 500.
Также инетерсно что с памятью, греет душу что один бинарник асинхронно отвечающий на запросы должен есть меньше чем несколько отдельных процессов в виде воркеров fpm. Если память нормально чистится.
по процессам авто по коннектам 1024
Спасет ли roadrunner franken если вам надо сделать стриминг видео, реал чат по вебсокетам)
Спасибо
👍
Недавно на канале, а столько инфы полезной , спасибо что освещаете такое, сам бы не нашел)))
Стараемся, спасибо за комментарий
Круто, но очень сложно)
👍
Очень интересная тема. Хотя пока железа хватает, что бы вытянуть мои приложения на php+laravel+nginx, постепенно увеличивается требования к железу за счет новых функций без которых никуда. По этому надо учить новые технологии. За видос Благодарю. Все понятно и без воды)
Всегда есть балансиры и горизонтальное масштабирование)
которое может оказаться в разы дешевле, чем искать новых разрабов под стек с RR
Лучше учить новый язык типа go lang или java которые из коробки работают
А когда поговорим про swoole?
Как потрогаю, сразу после поговорим
если у нас допустим стоит varnish и полностью кэширует страницы, а api запросы кэшируется в redis, получим ли мы какой-то прирост в итоге?
Привет! Ого, тему какую поднял!) А мне довелось перепробовать всё, включая Swoole, в боевых условиях.
Не нужен тебе RR и Spiral, возьми лучше Swoole и HyperF)
Я вот без шуток, получишь всё тоже самое, только быстрее в 5 раз, а ещё и Coroutine-optimized Eloquent ORM и много привычных из ларки вещей. У меня HyperF сейчас на бою (клиент-сервисы и микросервисы), несколько месяцев уже, работает быстро и стабильно. Держим нагрузочки так, что даже сервер не потеет.
Как работает HyperF с рендером HTML - я, честно, не знаю, мне кажется когда речь заходит о таких вещах, обычно фронт уже отделён давным-давно и общается с бэком по REST, WebSocket и т.п..
Что же касается Octane - конечно на RR или Swoole ларка будет лучше себя чувствовать, но она, как по мне, избыточна перегружена сама по себе. Как монолит для небольших проектов с небольшой нагрузкой - ок, но что то серьёзнее, пу-пу-пу...
P.s. для тех кто не в курсе, HyperF - это фреймворк который написан именно под Swoole, при этом сам Swoole это именно базовое PHP расширение написанное на C++. Во фреймворке реализована работа с БД (MySQL и PgSQL) на уровне самого расширения. Очень рекомендую затестить!!! Правда документация отвратительная, много чего не описано и не упомянуто, но есть всё, что нужно для работы, особенно если у вас микросервисы или вы планируете переход на такую архитектуру. Проект активно развивается, куда более популярен чем спиралька.
Привет! Спасибо за подробный комментарий! Честно говоря мне Swoole из за документации сразу не понравился и я на него пока не смотрел, но обязательно гляну и на HyperF тоже
Swoole шляпа по сравнению с корутинами в го. Если есть какая то причина делать асинхронность, лучше не делать это на php
Swoole не дружит с xdebug, а вардампить - такое. На любителя
@@igancev С версии Swoole 5.0.2 есть поддержка xdebug: Support xdebug under 8.1 or higher
HyperF gotask работают на нашем goridge, а openswoole используют наш grpc генератор :)
спасибо я ожидал это видео
Если golang решает проблемы php, то зачем тогда php?)
Логику проще писать на ООП
Потому что есть готовые проекты куда легче всего интегрировать такие вот сервера приложения типа rr, Franken дабы увеличить скорость. а времени нет все переписывать. Поэтому лучше доучивать сам go как доп язык.
Спасибо за инфу
Пожалуй да, давай побольше про roadrunner, будет очень интересно ее
👌
ниочем
спасибо за развернутое мнение
FrankenPHP worker mode работает быстрее чем roadrunner судя по бенчмаркам. Вы не проверяли?
@@you-are-not-allowed быстрее но он пока забагован, для продакшена не рекомендую
Геморроя больше чем пользы, время загрузки Фреймворка часто много меньше времени на остальную часть кода... Те кто это смотрит, никогда не будет использовать это в продакшине...
Я собеседовался и меня спросили про octane и roadranner . В той компании используют, и я в неё не попал. Думаю много кто перейдет, особенно крупные бизнесы.
Laravel сам по себе Геморой, чего только livewire стоит.
@@romanbush5164нормальные компании заставят учить golang
Nginx хорошо . Но хотелось бы Apache в тестах увидеть.
Апач сразу в мусорку
@@teletypewriter Ну кому как. Везде есть свои + и - . Мне в виду привычки удобней и приятней с Apache работать.
Дело не в удобстве, а чудовищных тормозах под нагрузкой
@@teletypewriter а как же подкрепления своих слов данными ?