Комментарии 39
Привет, 1000 человек онлайн это совсем не много — например у нас Centrifugo отъедает только 1% одного ядра CPU и 200мб памяти с 1к пользователями онлайн. Так что та же Центрифуга или dklab_realplexor, который часто упоминается в постах о PHP (в том числе и том, на который вы давали ссылку в тексте статьи), могут стать для вас лучшим выбором в конечном итоге.
Да, согласен. Но статьей я хотел больше доказать, что любой человек, который знает какой-нибудь язык программирования (не PHP) сможет написать свое highload-приложение. За Центрифугу спасибо :) Если будет возможность — попробую. Тем не менее, выше я упомянул, что вебсокеты как вариант отпали.
Не за что:) Я из статьи не очень хорошо понял, почему вебсокеты отпали как вариант. Если только из-за слабой браузерной поддержки, то оба решения, озвученных выше, используют fallback HTTP-транспорты, в том числе и long-polling (xhr-polling). Более того у нас 95% пользователей уже могут подключиться по вебсокетам (возможно в вашем случае эта цифра меньше, зависит от аудитории сайта). Если вы видите еще какую-то проблему с вебсокетами и просто не желаете их использовать — то их просто можно отключить и использовать только HTTP — xhr-streaming, eventsource, xhr-polling и более изощренные для совсем старых браузеров (iframe-htmlfile, jsonp-polling).
если использовать libevent Long-polling на php и c по реализации и производительности на 1k подключений (это не highload) практически не будет отличаться
Я не знаю, чем эта либа хороша, но простой скрипт на PHP даже без подключения базы, в стиле процедурного — сразу погасил сервер.
Может быть скрипт был написан не достаточно качественно?
не буду спорить относительно качества :) С PHP достаточно долго и реализовывал достаточно сложные вещи, да и перечитал много литературы чтобы правильно выбрать логику.
А вот к стати, цитата партнера, может просто нагрузка была больше 1000:
А вот к стати, цитата партнера, может просто нагрузка была больше 1000:
привет чат не упал я выключил его временно, у тебя на сайте онлайн вырос, было 300000 соеденений одновременных, так что ширины канала просто не хватило, не знаю даже что тут можно сделать, убери пока код с сайта
Судя по всему, или клиенты не ждали сообщения от сервера и открывали всё новые и новые коннекты, или сервер не закрывал соединения после отправки сообщений, а клиенты открывали всё новые и новые.
Возможно, ограничение по одновременно запущенным процессам Apache на вашем хостинге было тому виной? Сам с таким сталкивался. При лонгполле процессы убиваются не сразу, а с существенной задержкой, в этом причина быстрого затыка (если у вас Apache + PHP как модуль, а не php-fpm, конечно — в моём случае VPS тоже спас, но скорее благодаря тому, что там был nginx + mod_fpm).
Вам предстоит еще долго и упорно учиться. Задаться темой чата, реализовать его на php, выбрать при этом long polling и не знать при libevent это в наши дни, хм… немного безответственно.
Вы на каждое соединение цикл запускали? :)
Нужно делать общий цикл, который мониторит новые сообщения и возвращает их в соединение из пула. 1000 подключений — это совсем небольшая нагрузка.
Нужно делать общий цикл, который мониторит новые сообщения и возвращает их в соединение из пула. 1000 подключений — это совсем небольшая нагрузка.
Да, так и планировал сделать изначально. Но, к сожалению, не было достаточно времени для переработки компонента FPHTTPServer. Весь смысл сводился к ручному управлению потоками, но до перепила исходников я так и не добрался.
Учите Go, там это нетрудно реализовать :)
Синтаксис не впечатлил :) Да и не сильно копался в нем, может в этом и есть моя ошибка :). А чат хотел сделать кроссплатформенным, потому остановился на лазаре.
Как я помню — socket.io умеет сам делать выбор между сокетами и long pollin и кучей других способов в зависимости от «способностей» вашего браузера. Работает очень круто. Зря Вы отказались от node.js, тем более, как сказали выше 1000 — не такая уж и большая нагрузка.
сам делать выбор между сокетами
Оу, про это не в курсе. Сори, видимо недогуглил.
тем более, как сказали выше 1000 — не такая уж и большая нагрузка
Это то что я смотрел в реалтайме, по факту точное количество сказать не могу. Но вот смущает то, что партнер отказался от предоставления своего чата — сказал слишком много соединений из-за чего его сервер падал. На чем он построил свой чат я не знаю, но использовал он nodeJS.
Проблема с нодой в том, что внутри есть несколько моментов при которых происходит глобальное блокирование. Как следствие — все подключенные клиенты накрылись медным тазом. Более стабильный вариант erlang (VM под винду есть сразу в виде готового бинарника), но он по синтаксису и пониманию специфичный. Как пример: Comet–приложение для Mochiweb c нагрузкой в 1 000 000 пользователей.
C10k problem
Мы у себя используем nginx-pushstream-module. Libevent вам тут подсказывали намекая на Ratchet или ReactPHP тоже позволят вам держать поболее соединений
Мы у себя используем nginx-pushstream-module. Libevent вам тут подсказывали намекая на Ratchet или ReactPHP тоже позволят вам держать поболее соединений
Спасибо, для nginx модуль действительно стоящий. А по поводу PHP — сама его идеология не подходит. Я когда-то пытался писать драйвера на Delphi и получалось, но он для этого не предназначен
Какая идеология PHP вам мешает?
и смысл раскапывать этих мамонтов в которых 2009 год совсем недавно?
в php есть сборка мусора с поддержкой циклических ссылок как раз с 5.3, а в 7 версии можно фатальные ошибки обрабатывать в приложении, тоесть при желании оно ещё и фиг упадет, даже если вы какой-то левый код подключаете по мере работы, так, что в чем же он принципиально отличается от тойже ноды, питона и т.п. именно как язык + стандартная реализация?
в php есть сборка мусора с поддержкой циклических ссылок как раз с 5.3, а в 7 версии можно фатальные ошибки обрабатывать в приложении, тоесть при желании оно ещё и фиг упадет, даже если вы какой-то левый код подключаете по мере работы, так, что в чем же он принципиально отличается от тойже ноды, питона и т.п. именно как язык + стандартная реализация?
Сколько постов в секунду происходит в чате на 1000 человек, описанном в статье?
в секунду — 2-3 поста
Ну тогда думаю, что вы рано отказались от простого решения на PHP. Если нет особых ограничений по трафику, то Varnish на фронт — раздавать страницу чата аяксом (Varnish выдержит тысячи подключений в секунду даже на слабом VPS), а PHP только обновляет эту страницу в кеше Varnish и БД при новых постах. Все очень просто и без комет технологий.
PHP только обновляет эту страницу в кеше Varnish
Вот это и настораживает, не будет ли это то же самое, что и постоянный вызов скрипта php. С другой стороны, скрипт можно запустить в infinity, но такая реализация мне не нравится.
Нет, не будет, т.к. PHP скрипт вызывается только для постов клиента, т.е. 2-3 раза в секунду (как вы ранее описали) он обновляет кеш варниша и сразу же завершает свою работу, освобождая ресурсы. Для обновления чата клиент обычным аяксом запросом получает контент чата из варниша например раз в 5 сек. Итого имеем примерно 200 http запросов в секунду к варнишу, и 2-3 http запроса в секунду к PHP скрипту на вебсервере, что, повторюсь, даже для самого убогого VPS — вообще не проблема.
писать чат на PHP — бессмысленно, если нагрузка на него будет больше, чем 10 человек
про chatvdvoem на хабре
Сейчас там больше 1000 человек. И как, реально работает ровно на том стеке, что был изначально? Ресурсов сколько требует под себя?
i.imgur.com/3bgALml.jpg — это сайт в пассивном режиме. Процесс со всеми потоками съедает 1% оперативы и 5% процессора.
В час пик может доходить до 20% оперативы и 15% процессора
В час пик может доходить до 20% оперативы и 15% процессора
Рекомендую попробовать компонент lnet — https://lnet.wordpress.com
У меня он тащит 30-40 тыщ коннектов.
У меня он тащит 30-40 тыщ коннектов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Высокопроизводительный long polling чат