В ноябре тоже перенес свой проект на сервер приложений. Тестировал swoole, openswoole, roadrunner. В итоге остановился на swoole. В моем случае swoole и openswoole показали результаты лучше, чем roadrunner. Сравнивал я именно скорость ответа от бекэнда. Но стоит отметить, что и код свой я сильно не переписывал, а только избавился от синглтонов, статических методов и DI в методах контроллеров (DI теперь только в конструкторах). Но с чем я так и не разобрался, так это как дебажить )) Дебаг настроить я так и не смог ) Мне кажется это было бы отличной темой для видео. Информации по настройке отладки крайне мало.
@@roman_roman_roman_roman Замеры типа нагрузки на проц я не делал. Но точно могу сказать, что время ответа от бекенда уменьшилось в 2 раза. Это при том, что я не использовал Octane::concurrently. И у меня используется nginx как прокис + кеш статики.
Очень интересная тема. Хотя пока железа хватает, что бы вытянуть мои приложения на 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 тоже
Спасибо, интересо. Кстати, 500-ые при тестах fpm могли быть связаны с кончившимися воркерами, сколько их там было? Явно не 500. Также инетерсно что с памятью, греет душу что один бинарник асинхронно отвечающий на запросы должен есть меньше чем несколько отдельных процессов в виде воркеров fpm. Если память нормально чистится.
Потому что есть готовые проекты куда легче всего интегрировать такие вот сервера приложения типа rr, Franken дабы увеличить скорость. а времени нет все переписывать. Поэтому лучше доучивать сам go как доп язык.
Геморроя больше чем пользы, время загрузки Фреймворка часто много меньше времени на остальную часть кода... Те кто это смотрит, никогда не будет использовать это в продакшине...
Я собеседовался и меня спросили про octane и roadranner . В той компании используют, и я в неё не попал. Думаю много кто перейдет, особенно крупные бизнесы.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
В ноябре тоже перенес свой проект на сервер приложений. Тестировал swoole, openswoole, roadrunner. В итоге остановился на swoole. В моем случае swoole и openswoole показали результаты лучше, чем roadrunner. Сравнивал я именно скорость ответа от бекэнда. Но стоит отметить, что и код свой я сильно не переписывал, а только избавился от синглтонов, статических методов и DI в методах контроллеров (DI теперь только в конструкторах). Но с чем я так и не разобрался, так это как дебажить )) Дебаг настроить я так и не смог ) Мне кажется это было бы отличной темой для видео. Информации по настройке отладки крайне мало.
@@roman_roman_roman_roman Замеры типа нагрузки на проц я не делал. Но точно могу сказать, что время ответа от бекенда уменьшилось в 2 раза. Это при том, что я не использовал Octane::concurrently. И у меня используется nginx как прокис + кеш статики.
Брат, а Telescope не работает в данном случае?
Используй buggregator и symfony var dumper
Отличное видео, интересно подавали, спасибо
Недавно на канале, а столько инфы полезной , спасибо что освещаете такое, сам бы не нашел)))
Стараемся, спасибо за комментарий
Очень интересно, хотелось бы больше видео на данную тему
Сделаем
@@CutCodeRu ждём с нетерпением :)
++
++
Умер -- воскрес! с кем не бывает )))) ржал ))
@@gnidkoav 😄
Пожалуй да, давай побольше про roadrunner, будет очень интересно ее
👌
Огонь, спасибо!
🔥
Сделайте урок пуш уведомления
👌
++
❤❤
Очень интересная тема. Хотя пока железа хватает, что бы вытянуть мои приложения на php+laravel+nginx, постепенно увеличивается требования к железу за счет новых функций без которых никуда. По этому надо учить новые технологии. За видос Благодарю. Все понятно и без воды)
Всегда есть балансиры и горизонтальное масштабирование)
которое может оказаться в разы дешевле, чем искать новых разрабов под стек с RR
Лучше учить новый язык типа go lang или java которые из коробки работают
если у нас допустим стоит 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 генератор :)
Спасибо, интересо.
Кстати, 500-ые при тестах fpm могли быть связаны с кончившимися воркерами, сколько их там было? Явно не 500.
Также инетерсно что с памятью, греет душу что один бинарник асинхронно отвечающий на запросы должен есть меньше чем несколько отдельных процессов в виде воркеров fpm. Если память нормально чистится.
по процессам авто по коннектам 1024
Если хочется ускориться, но переписывать проект под Roadrunner, FrankenPHP или swoole нет возможности можно попробовать nginx unit
@@qqDAN4iKpp был опыт? И как все прошло?
Спасибо
👍
Круто, но очень сложно)
👍
Спасет ли roadrunner franken если вам надо сделать стриминг видео, реал чат по вебсокетам)
А когда поговорим про swoole?
Как потрогаю, сразу после поговорим
Если golang решает проблемы php, то зачем тогда php?)
Логику проще писать на ООП
Потому что есть готовые проекты куда легче всего интегрировать такие вот сервера приложения типа rr, Franken дабы увеличить скорость. а времени нет все переписывать. Поэтому лучше доучивать сам go как доп язык.
Я тоже так подумал, расстроился
Ждем уроки! Подписался, жду октан!)
🔥
Nginx хорошо . Но хотелось бы Apache в тестах увидеть.
Апач сразу в мусорку
@@teletypewriter Ну кому как. Везде есть свои + и - . Мне в виду привычки удобней и приятней с Apache работать.
Дело не в удобстве, а чудовищных тормозах под нагрузкой
@@teletypewriter а как же подкрепления своих слов данными ?
Геморроя больше чем пользы, время загрузки Фреймворка часто много меньше времени на остальную часть кода... Те кто это смотрит, никогда не будет использовать это в продакшине...
Я собеседовался и меня спросили про octane и roadranner . В той компании используют, и я в неё не попал. Думаю много кто перейдет, особенно крупные бизнесы.
Laravel сам по себе Геморой, чего только livewire стоит.
@@romanbush5164нормальные компании заставят учить golang
ниочем
спасибо за развернутое мнение
FrankenPHP worker mode работает быстрее чем roadrunner судя по бенчмаркам. Вы не проверяли?
@@you-are-not-allowed быстрее но он пока забагован, для продакшена не рекомендую