дорогой, тебе дать ссылку на правила клуба?
ты кто из?-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Чем php плох для реализации websocket сервера?
- Автор темы error1001es
- Дата начала
ты кто из?MiksIr
miksir@home:~$
Да можно "преодолевать", рождая тысячи воркеров на пхп, тратя ресурсы машины на спящие процессы и их переключение, используя пересист коннекты, потом не забыв подсунуть еще proxysql что бы эти висящие коннекты не убили базу... есть такие проекты... а можно написать сразу на голанге, который озеленит тебя тредами.
центрефуга поднимает вебсокеты, клиенты взаимодействуют с ним, подписываются на каналы, шлют ему сообщения. и на бэкенде из php ты через апи забираешь или посылаешь данные на центрефугу. в итоге тебе не надо держать толстый процесс на php с фреймворкой и прочей обвязкой. не надо париться о реализации вебсокета, не надо париться об утечках и блокировках.
в общем, погугль и почитай. хотя, возможно тебе и php реализации за глаза хватит.
preload и roadrunner решают проблему бутстрапинга, но не решают кучу других связанных с умиранием процессов. в полноценном демоне, тебе не надо постоянно лазить в базу и париться о кэше, так как данные шарятся в памяти и всякие идентити мэп у тебя работают не в рамках одного запроса, а в рамках всех, от этого куча плюсов и минусов.
Помимо редиса и его асинхронных клиентов, вечно забытый mysqli умеет в асинхронность.
Он умеет в асинхронность, но к сожалению, во первых с кучей "но" (начиная от того, что поддержку нужно явно компилять) а в главных - его нужно поллить для ответа, что довольно бессмысленно в evloop реализациях.
roadrunner - это appserver, процессы не умирают просто так, но он умеет только http,
для ws есть есть https://github.com/walkor/Workerman - там все готово из коробки, прямо первый пример
а до каналов ни roadrunner ни swoole не дорос, ipc придется ручками делать, но надо ли?
центрифуга или pushpin для web sockets - аналог nginx или apache в http просто по архитектуре,
никто ж не открывает ноду или golang в мир напрямую, всегда стоит http-сервер,
вместо центрифуги тот же nginx можно воткнуть, если не влом писать сервер приложения
вообще, вопрос ws на хабре 6 лет назад разжевали - как это делается безо всяких фреймвоков сотней строк кода, с балансировкой на nginx и master-worker моделью, разобраться можно за два часа
Последнее редактирование:
чукча не читатель, чучка писатель
MiksIr
miksir@home:~$
Да? А что именно я не так сказал? Что голанг освободит процессор от переключения между процессами, сидящими в iowait базы данных? Что из-за большого числа таких процессов будет увеличенное число idle коннектов в базу, тоже выжирающее ресурсы? Это все еще "golang ничего не даст?"
Это не так. Единственное что дает golang - это лучшее решение для ipc.
Когда работаешь с каналами в golang мьютексы захватываются и освобождаются автоматически.
В swoole каналы тоже есть, но ущербные.
Обрабатывать соединения в одном основном цикле в php можно точно так же, как в golang.
Это какая-то религия, что на php надо плодить пачку worker-ов для запросов к базе.
Любой условный каталог, например, отлично живет в памяти, и все, что у базы надо спрашивать - это timestamp записи, iowait не будет узким местом даже с блокирующим запросом.
А вот бюджет отладки багов на сайте, который написан на golang, с постановкой CI pipeline для сборки и деплоя - очень даже узкое место для проектов.
Это такой дурацкий флейм уже.
Последнее редактирование:
MiksIr
miksir@home:~$
Ну да, "проблему блокирования на iowait можно решить, если запихнуть все в память и не ходить в базу", гениально, чо
Универсальный совет на все случаи жизни.
Он просто слишком много здесь сидит, как и я.дорогой, тебе дать ссылку на правила клуба?
От этого очень сильно портится способность к коммуникации с людьми
там такая отсинхронность, что лучше бы её не было.
Запрос в рамках одного соединения можно только один. то есть отправивив запрос в БД, ты можешь посидеть покурить или что-то поделать ещё, но другой запрос, чтобы он выполнялся параллельно, ты не отправишь.
...и тут мы имеем классическую сложную проблему программирования (инвалидация кэша).
Я вот недавно в похожей ситуации выкинул кэш в памяти и сделал денормализацию в Redis. Медленнее, зато без багодрома.
Справедливости ради, сам mysql client-server protocol последовательный, т.е. гарантирует очередь исполнения запросов в пределах соединения. Т.е. для тебя там все равно будет очередь из твоих запросов. _Результаты_ запроса можно тянуть с сервера асинхронно, да, пока исполняется другой.
Да, для терминирования ssl и балансировки.
Принципиально это http-сервер ничего не добавляет.
Это решается пулом соединений.
Мне кажется, практическое ежедневное программирование это в принципе про "насколько далеко я могу зайти с самым простым вариантом решения"
да, но это никак не связано с "одним запросом при асинхронности" в случае mysqli конкретно
Конечно. Я про то, что масштабируем мы все же приложение, заменяя пачку процессов в iowait на один процесс в epoll. С пулом с точки зрения mysql ничего от такого перехода - от пачки процессов к одному с пулом соединений - не меняется, но вроде бы и не эту задачу же решали.
Ну и радости тогда с этой асинхронности?
Мне всегда казалось что основная нагрузка - это выполнене запроса, а не получаение результата.В общем случае "тянуть результаты" будет по затратам то же самое, что и полл - один TCP пакет.
Мне вот интересно дяденьки, вы уже не спите, или ещё не спите?