Comments 35
Больше трёх сообщений чатик Ваш не даёт отправить. НО! Перезагрузив страницу по новой логинимся и опять отправляем. Привязку к сессии сделать было бы неплохо.
С PDO есть проблема в том, что он синхронный. Т.е. пока запрос не выполнится все клиенты swoole ждут его завершения.
В swoole 4.1 добавили какую-то штуку по заворачиванию PDO и проч в асинхронную обертку (см https://pecl.php.net/package-changelog.php?package=swoole), но я не ковырял)
Хм… Я думал что суть их асинхронного подключения БД в возможности продолжить выполнять код в текущем воркере параллельно с запросом, а другие клиенты собственно в другом процессе выполняют свои запросы. Займусь этим вопросом.
upd: Запустил через PDO и корутины долгие запросы к MySQL, проследил за выполняющимися процессами.
Вы правы насчёт синхронности PDO. Впрочем, в текущих условиях это не принипиально
Когда я писал это не смог по быстрому осилить установку mysqlnd на моей системе
Вы правы насчёт синхронности PDO. Впрочем, в текущих условиях это не принипиально
Когда я писал это не смог по быстрому осилить установку mysqlnd на моей системе
Асинхронные серверы на подходящих для того языках типа ноды или го — это для слабаков!
Только пхп, только гланды через назад!
Я пробовал Swoole год назад. Из того что помню:
Пока делал специфичный чат, вышла новая версия, вроде 2.2. Но новая версия не смогла собраться со всеми нужными мне пакетами на убунту 16.04 (вебсокеты не собирались). Не работали корутины.
Делал просто сервер, данные хранил в swoole_table.
Еще была ошибка, что не мог пушануть ответ, из-за каких то вложеностей вызовов функций. Гуглил, такое бывает, решение которое предлагали китайцы(основные разработчики) прислать им дебаг инфу на Си.
Пришлось переписать проще, чтобы логика была в функции onMessage сразу.
Создалось впечатление, что сырой продукт еще. И пожалел, что не стал использовать ReactPHP. Более привычно для ПХПшника.
В общем работает, соединения не рвет, как у вас. Но у меня другая версия была.
Но может просто я не понял swoole :)
Пока делал специфичный чат, вышла новая версия, вроде 2.2. Но новая версия не смогла собраться со всеми нужными мне пакетами на убунту 16.04 (вебсокеты не собирались). Не работали корутины.
Делал просто сервер, данные хранил в swoole_table.
Еще была ошибка, что не мог пушануть ответ, из-за каких то вложеностей вызовов функций. Гуглил, такое бывает, решение которое предлагали китайцы(основные разработчики) прислать им дебаг инфу на Си.
Пришлось переписать проще, чтобы логика была в функции onMessage сразу.
Создалось впечатление, что сырой продукт еще. И пожалел, что не стал использовать ReactPHP. Более привычно для ПХПшника.
В общем работает, соединения не рвет, как у вас. Но у меня другая версия была.
Но может просто я не понял swoole :)
Уже v4.1.0: )
В в новой версии я таких багов не встречал, надеюсь что это не только моё везение.
Конечно, не всё идеально
Но серьёзных косяков вроде нет, а если что авторы всегда очень шустро отвечают, и стараются фиксить найденные баги.
В в новой версии я таких багов не встречал, надеюсь что это не только моё везение.
Конечно, не всё идеально
Но серьёзных косяков вроде нет, а если что авторы всегда очень шустро отвечают, и стараются фиксить найденные баги.
Можно подойти к проблеме с другой стороны и заниматься многопоточностью над ПХП: https://github.com/spiral/roadrunner
Нагрузочное тестирование не проводили?
Лично я нет, но в интернете и в т.ч. у них на сайте(или на гитхабе, не помню точно), выкладывались результаты тестирования и используемый код.
Вот нашёл например: www.swoole.co.uk/benchmark, правда тестировалась старая версия
Вот нашёл например: www.swoole.co.uk/benchmark, правда тестировалась старая версия
По прежнему считаю PHP самым удачным и лучшим интерпретатором. Каноничный C-подобный синтаксис (без всяких вот этих ваших «удобочитаемых» ЯП), а так же максимально приближенное к реальности ООП.
Не забывайте что язык — всего лишь инструмент для достижения поставленных целей, и может меняться в зависимости от задач: )
> а так же максимально приближенное к реальности ООП.
значит вы плохо понимаете что такое это самое ООП. В этом плане наиболее «приближен к реальности» Erlang. А если под ООП вы классы подразумеваете — без inner классов хотя бы сложно структурировать адекватно, все время приходится на компромисы какие-то идти.
Ну и в целом PHP как язык — очень плох. Прям очень (чаще всего выражается это в полумерах, принятых в языке). И если вам так не кажется — то либо мы говорим о PHP как о платформе (с этой точки зрения все прекрасно) либо у вас специфичные вкусы.
На сегодняшний день у php достаточно конкурентов, и аргумент что разработчиков найти проще уже не очень правда… во всяком случае адекватных разработчиков найти не проще чем на любом другом языке.
значит вы плохо понимаете что такое это самое ООП. В этом плане наиболее «приближен к реальности» Erlang. А если под ООП вы классы подразумеваете — без inner классов хотя бы сложно структурировать адекватно, все время приходится на компромисы какие-то идти.
Ну и в целом PHP как язык — очень плох. Прям очень (чаще всего выражается это в полумерах, принятых в языке). И если вам так не кажется — то либо мы говорим о PHP как о платформе (с этой точки зрения все прекрасно) либо у вас специфичные вкусы.
На сегодняшний день у php достаточно конкурентов, и аргумент что разработчиков найти проще уже не очень правда… во всяком случае адекватных разработчиков найти не проще чем на любом другом языке.
1. ООП в PHP — имеется ввиду относительно других интерпретаторов, нацеленных на вэб-разработку
2. Erlang имеет далеко не самый приятный стиль программирования (об «удобочитаемом» синтаксисе — я молчу), да и придуман он как раз для других задач
3. Есть вещи, которые уже устаканились временем:
— хочешь приложение для эпловской системы — используешь Swift
— хочешь приложение для виндовой системы — используешь C#
— хочешь приложение для вэба — используешь для клиента — JS, для сервера — PHP
— хочешь сделать что-то кроссплатформенное — используешь Java
В большинстве случаев — этого хватает с головой, если присутствуют специфические задачи, или «вкусы», вот только тогда, либо прибегают к использованию других ЯП, либо создают свой новый ЯП.
Относительно высосаных из пальца аргументов, есть такое понятие — брэнд(ы), они приходят и уходят (это я об ваших конкурентах, если что), остается лишь рабочее средство, проверенное временем. (сори за тавтологию).
В общем, мой посыл в том, что есть уже всем привычное ООП (java-like) c реально понятным С-подобным синтаксисом, которое работает и не приносит такой большой боли и страдания (относительно НЕ специфических задач и вкусов).
2. Erlang имеет далеко не самый приятный стиль программирования (об «удобочитаемом» синтаксисе — я молчу), да и придуман он как раз для других задач
3. Есть вещи, которые уже устаканились временем:
— хочешь приложение для эпловской системы — используешь Swift
— хочешь приложение для виндовой системы — используешь C#
— хочешь приложение для вэба — используешь для клиента — JS, для сервера — PHP
— хочешь сделать что-то кроссплатформенное — используешь Java
В большинстве случаев — этого хватает с головой, если присутствуют специфические задачи, или «вкусы», вот только тогда, либо прибегают к использованию других ЯП, либо создают свой новый ЯП.
Относительно высосаных из пальца аргументов, есть такое понятие — брэнд(ы), они приходят и уходят (это я об ваших конкурентах, если что), остается лишь рабочее средство, проверенное временем. (сори за тавтологию).
В общем, мой посыл в том, что есть уже всем привычное ООП (java-like) c реально понятным С-подобным синтаксисом, которое работает и не приносит такой большой боли и страдания (относительно НЕ специфических задач и вкусов).
- я к тому что я понятия не имею что вы под ООП имеете ввиду.
- Есть Elixir, у него синтаксис поприятнее. Что до "других задач" — ну вот то куда люди свулле впихивают как раз таки "те самые другие задачи".
- Swift можно использовать хоть для бэкэнд разработки хоть для фронтэнда (webassembly). Это ваши стереотипы. Так же как и Kotlin native можно юзать для написания экстеншенов для php. C# так же вполне себе юзабелен для кросплатформенной разработки нынче. Для вэба — опять же выбор сильно больше, ну и опять же — подождем годика три пока webassembly наберет популярность. А так уже сегодня многие используют различные трансляторы в js.
Как там говорится, прогресс движется в сторону интеропа языков и это хорошо.
Относительно высосаных из пальца аргументов
еще раз, я против php как платформы ничего не имею, использую его на протяжении 10-ти лет. Но повторюсь, язык убогий.
уже всем привычное ООП (java-like)
посмотрите как в той же джаве можно красиво билдеры описать и грустите что подобного в php не будет. Нет, ну может быть вот это протащат и я тогда буду меньше ругаться, но…
А пока все эти "самый лучший интерпритатор" и прочие восхваления языка лишь вред ему несут.
Fesor
Лично меня php устраивает, что-то нравится, а что-то нет, но по большей части нравится. Тоже самое и с другими языками. Кучу людей не устраивает java, кого-то golang, но никто в своём уме не пишет, что у тех кому они нравятся — «специфичные вкусы». Язык программирования — не 100 баксов, чтобы нравиться всем. К тому же подход к выбору языка «нравится/не нравится» не очень объективный, ведь это особенность работы нашего мозга — ему нравится знакомое.
Именно по этому, когда стоит задача «прикрутить вебсокеты», чаще берут решение, которое позволяет это сделать на знакомом языке и для php-разработчика самые частые решения — это swoole, workerman и т.д., потом node.js, а уже только затем golang, erlang, python и т.д.
Ну и в целом PHP как язык — очень плох. Прям очень… И если вам так не кажется — то… у вас специфичные вкусы.Вы называете большинство веб-разработчиков — ''извращенцами", только потому что они имеют отличный от вашего вкус? При этом вы сами используете php на протяжении 10-ти лет… Вы извращенец или мазохист?
Лично меня php устраивает, что-то нравится, а что-то нет, но по большей части нравится. Тоже самое и с другими языками. Кучу людей не устраивает java, кого-то golang, но никто в своём уме не пишет, что у тех кому они нравятся — «специфичные вкусы». Язык программирования — не 100 баксов, чтобы нравиться всем. К тому же подход к выбору языка «нравится/не нравится» не очень объективный, ведь это особенность работы нашего мозга — ему нравится знакомое.
Именно по этому, когда стоит задача «прикрутить вебсокеты», чаще берут решение, которое позволяет это сделать на знакомом языке и для php-разработчика самые частые решения — это swoole, workerman и т.д., потом node.js, а уже только затем golang, erlang, python и т.д.
> Вы извращенец или мазохист?
вы фразу видимо не дочитали. PHP отличная платформа со своими изюминками (вроде умирающей модели выполнения, алицетворяющей феникса). Вот эта самая платформа и привлекает людей. Платформа, а не язык.
В возможно вы вовсе и не про язык а про интерпритатор говорили. В таком случае смысл вашего комментария для меня остается загадкой.
вы фразу видимо не дочитали. PHP отличная платформа со своими изюминками (вроде умирающей модели выполнения, алицетворяющей феникса). Вот эта самая платформа и привлекает людей. Платформа, а не язык.
В возможно вы вовсе и не про язык а про интерпритатор говорили. В таком случае смысл вашего комментария для меня остается загадкой.
Платформа -> Архитектура -> Язык -> Интерпретатор -> Вкусы..., мб еще на атомы расщеплять будем???
Что имелось ввиду: PHP имеет (относительно) всем привычный C-подобный синтаксис и отличное ООП. Он создан конкретно для вэба, и в целом подходит для подавляющего большинства задач (серверная часть).
Что имелось ввиду: PHP имеет (относительно) всем привычный C-подобный синтаксис и отличное ООП. Он создан конкретно для вэба, и в целом подходит для подавляющего большинства задач (серверная часть).
и отличное ООП
Как вы сделали такой вывод?
всем привычный C-подобный синтаксис
как и половина других языков программирования.
Он создан конкретно для вэба
А еще он создавался как шаблонизатор для Си. Это тоже будем вспоминать?
и в целом подходит для подавляющего большинства задач
Не спорю, и он прекрасно с ними справляется. Как платформа. Но язык довольно неконсистентный, и в нем масса крайне сомнительных решений.
В вашей картинке есть сравнение swoole с чем угодно кроме главного конкурента workerman.
Во время участия в highloadcup, я сделал такое сравнение и в синтетическом тесте swoole оказался быстрее чем workerman менее чем на 10%, а в реальном разница была пару процентов.
При этом swoole_table жрал памяти в 20 раз больше чем лучшее решение.
В общем для конкурса я оставил swoole, потому что там была важна каждая микросекунда. В реальности же я использую workerman, потому что:
были и другие мелочи, которые приходилось терпеть, то что можно было бы исправить в workerman за 5 минут.
Во время участия в highloadcup, я сделал такое сравнение и в синтетическом тесте swoole оказался быстрее чем workerman менее чем на 10%, а в реальном разница была пару процентов.
При этом swoole_table жрал памяти в 20 раз больше чем лучшее решение.
В общем для конкурса я оставил swoole, потому что там была важна каждая микросекунда. В реальности же я использую workerman, потому что:
- у него лучше документация (к тому же всегда можно прочесть код в php-исходниках, чтобы разобраться),
- доработка под себя (средний php-разработчик может дописать php-библиотеку, а сишную — нет)
- более быстрое развитие (любой php-разработчик может отправить пулл-реквест в воркерман, а в случае swoole приходится ждать, когда его разработчики напишут/не напишут то что тебе требуется)
были и другие мелочи, которые приходилось терпеть, то что можно было бы исправить в workerman за 5 минут.
Спасибо за развернутый комментарий. Статью вашу я конечно же читал ещё когда искал информацию про Swoole, и сейчас только понял что та issue на Github «Why is swoole table so expensive» была от вас).
В принципе данные, если они должны лежать в памяти можно писать в Redis. А на постоянное хранение — в MySQL.
А можете рассказать, каких мелочей не хватало в Swoole?
Думаю займусь и изучением WorkerMan ради интереса.
В принципе данные, если они должны лежать в памяти можно писать в Redis. А на постоянное хранение — в MySQL.
А можете рассказать, каких мелочей не хватало в Swoole?
Думаю займусь и изучением WorkerMan ради интереса.
На вскидку, могу вспомнить нотисы, которые вылезали в консоли, если вебсокет закрывается не кодом на js, а просто закрытием вкладки (т.е. ситуация достаточно стандартная) и подобные мелочи.
Было два режима SWOOLE_BASE и SWOOLE_TASK (дефолтный), внятного описания не было даже на китайском.
Были какие-то проблемы с воркерами. То что мне нужно было в альфе и я ловил ошибки.
В любом случае, большое спасибо за статью. Это первая статья про swoole на хабре. Я сам о нём узнал буквально полтора-два года назад, хотя вроде как в теме «вебсокеты на пхп» я не чужой. Swoole / workerman достойно справляются со своими задачами и будут с ними справляться до выхода php8, где всё это обещают уже из коробки.
Было два режима SWOOLE_BASE и SWOOLE_TASK (дефолтный), внятного описания не было даже на китайском.
Были какие-то проблемы с воркерами. То что мне нужно было в альфе и я ловил ошибки.
В любом случае, большое спасибо за статью. Это первая статья про swoole на хабре. Я сам о нём узнал буквально полтора-два года назад, хотя вроде как в теме «вебсокеты на пхп» я не чужой. Swoole / workerman достойно справляются со своими задачами и будут с ними справляться до выхода php8, где всё это обещают уже из коробки.
Откуда КДПВ? Удивляет очень плохой результат Phalcon'а, а ведь он тоже написан на Си и по многим бенчмаркам он показывает большую производительность, чем, к примеру, фреймворки написанные на чистом PHP.
Хотелось бы изучить детально методы которые использовались для сравнения.
Хотелось бы изучить детально методы которые использовались для сравнения.
EvgeniiR
Спасибо, теперь понятно почему workerman показал в этом тесте такие низкие результаты. В докер-контейнере не установлен libevent.
megasween
Спасибо, теперь понятно почему workerman показал в этом тесте такие низкие результаты. В докер-контейнере не установлен libevent.
megasween
Удивляет очень плохой результат Phalcon'аСобственно Phalcon на графике выше yii2 и kohana, но логично медленнее чем swoole, ведь Phalcon — это целое приложение, а swoole — всего один файл.
Phalcon призван уменьшить оверхэд на бутстраппинг фреймворка, однако этот оверхэд все же есть. Свулле же это полноценный application server, а потому такие штуки как «отдать json» для него фигня. Из вариантов не требующих «переписи» лично мне нравится roadrunner. Будет не так круто как со свулле но я предпочел бы писать подобное не на php.
А вот почему такая огромная разница с тем же amp (разве что парсинг http запросов силами php) — это для меня загадка.
А вот почему такая огромная разница с тем же amp (разве что парсинг http запросов силами php) — это для меня загадка.
Sign up to leave a comment.
Пишем онлайн чат на Websockets используя Swoole