Разработка высоконагруженного WebSocket-сервиса

Как создать веб-сервис, который будет взаимодействовать с пользователями в реальном времени, поддерживая при этом несколько сотен тысяч коннектов одновременно?

Всем привет, меня зовут Андрей Клюев, я разработчик. Недавно я столкнулся с такой задачей – создать интерактивный сервис, где пользователь может получать быстрые бонусы за свои действия. Дело осложнялось тем, что в проекте были довольно высокие требования по нагрузке, а сроки были крайне невелики.

В этой статье я расскажу, как выбирал решение для реализации websocket-сервера под непростые требования проекта, с какими проблемами столкнулся в процессе разработки, а также скажу несколько слов о том, как в достижении вышеуказанных целей может помочь конфигурирование ядра Linux.

В конце статьи приведены полезные ссылки на инструменты разработки, тестирования и мониторинга.

Задачи и требования


Требования к функционалу проекта:


  • сделать возможным отслеживание присутствия пользователя на ресурсе и трекинг времени просмотра;
  • обеспечить быстрый обмен сообщениями между клиентом и сервером, так как время на получение пользователем бонуса строго ограничено;
  • создать динамичный интерактивный интерфейс с синхронизацией всех действий при работе пользователя с сервисом через несколько вкладок или устройств одновременно.

Требования к нагрузке:


  • Приложение должно выдерживать не менее 150 тысяч пользователей онлайн.

Срок реализации – 1 месяц.

Выбор технологии


Сопоставив задачи и требования проекта, я пришел к выводу, что для его разработки целесообразнее всего использовать технологию WebSocket. Она обеспечивает постоянное соединение с сервером, избавляя от оверхеда на новое соединение при каждом сообщении, которое присутствует в реализации на технологиях ajax и long-polling. Это позволяет получить необходимую высокую скорость обмена сообщениями в сочетании с адекватным потреблением ресурсов, что очень важно при высоких нагрузках.

Также благодаря тому, что установка и разрыв соединения – это два четких события, появляется возможность с высокой точностью отслеживать время присутствия пользователя на сайте.

Учитывая достаточно ограниченные сроки проекта, я принял решение вести разработку с помощью WebSocket-фреймворка. Изучил несколько вариантов, самыми интересными из которых мне показались PHP ReactPHP, PHP Ratchet, Node.JS websockets/ws, PHP Swoole, PHP Workerman, Go Gorilla, Elixir Phoenix. Их возможности в плане нагрузки тестировал на ноутбуке с процессором Intel Core i5 и 4 ГБ оперативной памяти (таких ресурсов было вполне достаточно для исследования).

PHP Workerman – асинхронный событийно-ориентированный фреймворк. Его возможности исчерпываются простейшей реализацией websocket-сервера и умением работать с библиотекой libevent, нужной для обработки асинхронных оповещений о событиях. Код находится на уровне PHP 5.3 и не соответствует никаким стандартам. Для меня главным минусом стало то, что фреймворк не позволяет реализовывать высоконагруженные проекты. На тестовом стенде разработанное приложение уровня «Hello World» не смогло удержать и тысячи коннектов.

ReactPHP и Ratchet по своим возможностям в целом сопоставимы с Workerman. Ratchet внутри зависит от ReactPHP, работает также через libevent и не позволяет создать решение для высоких нагрузок.

Swoole – интересный фреймворк, написанный на C, подключается как расширение для PHP, имеет средства для параллельного программирования. К сожалению, я обнаружил, что фреймворк недостаточно стабилен: на тестовом стенде он обрывал каждый второй коннект.

Далее я рассмотрел Node.JS WS. Этот фреймворк показал неплохие результаты – около 5 тысяч коннектов на тестовом стенде без дополнительных настроек. Однако мой проект подразумевал заметно более высокие нагрузки, поэтому я остановил свой выбор на фреймворках Go Gorilla + Echo Framework и Elixir Phoenix. Эти варианты тестировались уже более детально.

Нагрузочное тестирование


Для тестирования использовались такие инструменты как artillery, gatling и сервис flood.io.

Целью тестирования было изучение потребления ресурсов процессора и памяти. Характеристики машины были такими же – процессор Intel iCore 5 и 4 ГБ оперативной памяти. Тесты проводились на примере простейших чатов на Go и Phoenix:

Вот такое простое приложение чата нормально функционировало на машине указанной мощности при нагрузке 25-30 тысяч пользователей:

config:
  target: "ws://127.0.0.1:8080/ws"
  phases
    -
      duration:6
      arrivalCount: 10000
  ws:
    rejectUnauthorized: false
scenarios:
  -
    engine: “ws”
    flow
      -
        send “hello”
      -
        think 2
      -
        send “world”

Class LoadSimulation extends Simulation {

  val users = Integer.getInteger (“threads”, 30000)
  val rampup   = java.lang.Long.getLong (“rampup”, 30L)
  val duration  = java.lang.Long.getLong (“duration”, 1200L)
 
  val httpConf = http
    .wsBaseURL(“ws://8.8.8.8/socket”)

  val scn = scenario(“WebSocket”)
    .exes(ws(“Connect WS”).open(“/websocket?vsn=2.0.0”))
    .exes(
      ws(“Auth”)
        sendText(“““[“1”, “1”, “my:channel”, “php_join”, {}]”””)
    )
    .forever() {
      exes(
        ws(“Heartbeat”).sendText(“““[null, “2”, “phoenix”, “heartbeat”, {}]”””)
      )
      .pause(30)
  }
  .exes(ws(“Close WS”).close)

setUp(scn.inject(rampUsers(users) over (rampup seconds)))
  .maxDuration(duration)
  .protocols(httpConf)

Тестовые запуски показали, что все спокойно работает на машине указанной мощности при нагрузке 25-30 тысяч пользователей.

Потребление ресурсов процессора:

Phoenix

image

Gorilla

image

Потребление оперативной памяти при нагрузке в 20 тысяч соединений доходило до 2 ГБ в случае с обоими фреймворками:

Phoenix

image

Gorilla

image

При этом Go даже опережает Elixir по производительности, однако Phoenix Framework при этом предоставляет намного больше возможностей. На графике ниже, который показывает потребление сетевых ресурсов, можно заметить, что в тесте Phoenix передается в 1,5 раза больше сообщений. Это связано с тем, что у этого фреймворка уже в изначальной «коробочной» версии есть механизм heartbeat’ов (периодических синхронизирующих сигналов), который в Gorilla придется реализовывать самостоятельно. В условиях ограниченных сроков любая дополнительная работа была весомым аргументом в пользу Phoenix.

Phoenix

image

Gorilla

image

О Phoenix Framework


Phoenix – это классический MVC-фреймворк, достаточно похожий на Rails, что не удивительно, так как одним из его разработчиков и создателем языка Elixir является Хосе Валим – один из основных создателей Ruby on Rails. Некоторое сходство можно увидеть даже в синтаксисе.

Phoenix:

defmodule Benchmarker.Router do
  use Phoenix.Router
  alias Benchmarker.Controllers
  
  get "/:title", Controllers.Pages, :index, as: :page
end

Rails:

Benchmarker::Application.routes.draw do
  root to: "pages#index"
  get "/:title", to: "pages#index", as: :page
end

Mix – автоматизирующая утилита для Elixir-проектов


При использовании Phoenix и языка Elixir значительная часть процессов выполняется посредством утилиты Mix. Это инструмент для сборки (build tool), который решает множество разных задач по созданию, компиляции и тестированию приложения, по управлению его зависимостями и по некоторым другим процессам.
Mix – ключевая часть любого Elixir-проекта. Эта утилита ничем не уступает и ничем не превосходит аналоги из других языков, но справляется со своей работой на отлично. А благодаря тому, что Elixir-код выполняется на виртуальной машине Erlang, появляется возможность добавлять в зависимости любые библиотеки из мира Erlang. Помимо этого вместе с Erlang VM вы получаете удобный и безопасный параллелизм, а также высокую отказоустойчивость.

Проблемы и решения


При всех достоинствах у Phoenix есть и свои недостатки. Один из них заключается в сложности решения такой задачи, как отслеживание активных пользователей на сайте в условиях высокой нагрузки.
Дело в том, что пользователи могут подключаться к разным нодам приложения, и каждая нода будет знать лишь о собственных клиентах. Чтобы вывести список активных пользователей, придется опрашивать все ноды приложения.
Для решения этих проблем в Phoenix’е существует модуль Presence, который дает разработчику возможность отслеживать активных пользователей буквально в три строки кода. Он использует механизм хартбитов и бесконфликтной репликации внутри кластера, а также PubSub-сервер для обмена сообщениями между нодами.

image

Звучит хорошо, но на деле получается примерно следующее. Сотни тысяч подключающихся и отключающихся пользователей порождают миллионы сообщений на синхронизацию между нодами, из-за чего потребление ресурсов процессора переходит все допустимые пределы, и даже подключение Redis PubSub не спасает ситуацию. Список пользователей дублируется на каждой ноде, и расчет дифа при каждом новом подключении становится все дороже и дороже – и это учитывая, что расчет проводится на каждой из действующих нод.

image

В такой ситуации отметка даже в 100 тысяч клиентов становится недостижимой. Других готовых решений для данной задачи найти не удалось, поэтому я решил поступить следующим образом: возложить обязанность по мониторингу присутствия пользователей онлайн на БД.

На первый взгляд, это хорошая идея, в которой нет ничего сложного: достаточно хранить в базе поле last activity и периодически его обновлять. К сожалению, для проектов с высокой нагрузкой это не выход: когда количество пользователей достигнет нескольких сотен тысяч, система не справится с миллионами приходящих от них хартбитов.

Я выбрал менее тривиальное, но более производительное решение. При подключении пользователя для него создается уникальная строка в таблице, которая хранит в себе его идентификатор, точное время входа и список нод, к которым он подключен. Перечень нод хранится в JSONB-поле, и при конфликте строк достаточно его обновить.

create table watching_times (
  id serial not null constraint watching_times_pkey primary key,
  user_id integer,
  join_at timestamp,
  terminate_at timestamp,
  nodes jsonb
);

create unique index watching_times_not_null_uni_idx
  on watching_times (user_id, terminate_at)
  where (terminate_at IS NOT NULL);
 
create unique index watching_times_null_uni_idx
  on watching_times (user_id)
  where (terminate_at IS NULL);

Вот такой запрос отвечает за вход пользователя:

INSERT INTO watching_times (
  user_id,
  join_at,
  terminate_at,
  nodes
)
VALUES (1, NOW(), NULL, '{nl@192.168.1.101”: 1}')
ON CONFLICT (user_id)
  WHERE terminate_at IS NULL
  DO UPDATE SET nodes = watching_times.nodes ||
      CONCAT(
        '{nl@192.168.1.101:',
        COALESCE(watching_times.nodes->>'nl@192.168.1.101', '0')::int + 1, 
        '}'
      )::JSONB
RETURNING id;

Список нод при этом выглядит так:

image

Если пользователь открывает сервис во втором окне или на другом устройстве, он может попасть на другую ноду, и тогда она тоже добавится в список. Если он попадет на ту же ноду, что и в первом окне, число напротив названия этой ноды в списке увеличится. Это число отражает количество активных подключений пользователя к конкретной ноде.

Вот так выглядит запрос, который идет в БД при закрытии сессии:

UPDATE watching_times
SET nodes
  CASE WHEN
    (
      CONCAT(
        '{“nl@192.168.1.101”: ',
        COALESCE(watching_times.nodes ->> 'nl@192.168.1.101', '0') :: INT - 1,
        '}'
      )::JSONB ->>'nl@192.168.1.101'
    )::INT <= 0
  THEN
    (watching_times.nodes - 'nl@192.168.1.101')
  ELSE
    CONCAT(
      '{“nl@192.168.1.101”: ',
      COALESCE(watching_times.nodes ->> 'nl@192.168.1.101', '0') :: INT - 1,
      '}'
    )::JSONB
  END
 ),
 terminate_at = (CASE WHEN ... = '{}' :: JSONB THEN NOW() ELSE NULL END)
WHERE id = 1;

Список нод:

image

При закрытии сессии на определенной ноде счетчик подключений в БД уменьшается на единицу, а при достижении нуля нода убирается из списка. Когда список нод окончательно опустеет, этот момент будет зафиксирован как окончательное время выхода пользователя.

Данный подход дал возможность не только отслеживать присутствие пользователя онлайн и время просмотра, но и фильтровать эти сессии по различным критериям.

Во всем этом остается лишь один недостаток – если нода падает, все ее пользователи «зависают» в онлайне. Для решения данной проблемы у нас есть демон, который периодически чистит БД от таких записей, но до сих пор этого не требовалось. Анализ нагрузки и мониторинг работы кластера, проведенные после выхода проекта в продакшн, показали, что падений нод не было и данный механизм не использовался.

Были и другие трудности, но они более специфичны, поэтому стоит перейти к вопросу отказоустойчивости приложения.

Конфигурирование ядра Linux для повышения производительности


Написать хорошее приложение на производительном языке – это только половина дела, без грамотных DevOps достигнуть хоть сколько-нибудь высоких результатов невозможно.
Первой преградой на пути к целевой нагрузке стало сетевое ядро Linux. Потребовалось произвести некоторые настройки, чтобы добиться более рационального использования его ресурсов.
Каждый открытый сокет – это файловый дескриптор в Linux, а их число ограничено. Причина лимита в том, что для каждого открытого файла в ядре создается C-структура, которая занимает unreclaimable-память ядра.

Чтобы использовать память по максимуму, я выставил очень высокие значения размеров буферов приема и передачи, а также увеличил размер буферов TСP сокетов. Значения здесь выставляются не в байтах, а в страницах памяти, обычно одна страница равна 4 кБ, и на максимальное количество открытых сокетов, ожидающих соединения для высоконагруженных серверов, я поставил значение 15 тысяч.

Лимиты файловых дескрипторов:


#!/usr/bin/env bash
sysctl -w 'fs.nr_open=10000000' # Максимальное количество открытых файловых дескрипторов

sysctl -w  'net.core.rmem_max=12582912' # Максимальный размер буферов приема всех типов
sysctl -w 'net.core.wmem_max=12582912' # Максимальный размер буферов передачи всех типов

sysctl -w 'net.ipv4.tcp_mem=10240 87380 12582912' # Объем памяти TCP сокета
sysctl -w 'net.ipv4.tcp_rmem=10240 87380 12582912' # размер буфера приема
sysctl -w 'net.ipv4.tcp_wmem=10240 87380 12582912'# размер буфера передачи

<code>sysctl -w 'net.core.somaxconn=15000' # Максимальное число открытых сокетов, ждущих соединения

Если вы используете nginx перед cowboy-сервером, то стоит также задуматься об увеличении его лимитов. За это отвечают директивы worker_connections и worker_rlimit_nofile.

Вторая преграда не столь очевидна. Если запустить подобное приложение в распределенном режиме, можно заметить резкий рост потребления ресурсов процессора при увеличении количества коннектов. Проблема в том, что Erlang по умолчанию работает с системными вызовами Poll. В версии 2.6 ядра Linux существует Epoll, который может предоставить более эффективный механизм для приложений, обрабатывающих большое количество одновременно открытых соединений — со сложностью O(1) в отличие от Poll, обладающего сложностью O(n).

К счастью, режим Epoll включается одним флагом: +K true, также рекомендую увеличить максимальное количество процессов, порождаемых вашим приложением, и максимальное количество открытых портов с помощью флагов +P и +Q соответственно.

Poll vs. Epoll


#!/usr/bin/env bash
Elixir --name ${MIX_NODE_NAME}@${MIX_HOST} --erl “-config sys.config -setcookie ${ERL_MAGIC_COOKIE} +K true +Q 500000 +P 4194304” -S mix phx.server

Третья проблема более индивидуальна, и не каждый может с ней столкнуться. На данном проекте был организован процесс автоматического деплоя и динамического скейлинга с помощью Сhef и Kubernetes. Kubernetes позволяет быстро разворачивать Docker-контейнеры на большом количестве хостов, и это очень удобно, однако заранее узнать ip-адрес нового хоста нельзя, а если не прописать его в конфиг Erlang, подключить новую ноду к распределенному приложению не получится.

К счастью, для решения этих проблем существует библиотека libcluster. Общаясь с Kubernetes по API, она в режиме реального времени узнает о создании новых нод и регистрирует их в кластере erlang.

config :libcluster,
  topologies: [
    k8s: [
      strategy: Cluster.Strategy.Kubernetes,
      config: [
        kubernetes_selector: “app=my -backend”,
        kubernetes_node_basename: “my -backend”]]]

Итоги и перспективы


Выбранный фреймворк в сочетании с правильной настройкой серверов позволил достичь всех целей проекта: в поставленные сроки (1 месяц) разработать интерактивный веб-сервис, который общается с пользователями в режиме реального времени и при этом выдерживает нагрузки от 150 тысяч коннектов и выше.

После запуска проекта в продакшн был проведен мониторинг, который показал следующие результаты: при максимальном количестве коннектов до 800 тысяч потребление ресурсов процессора доходит до 45%. Среднее значение загрузки составляет 29% при 600 тысячах соединений.

image

На этом графике – потребление памяти при работе в кластере 10 машин, каждая из которых имеет по 8 ГБ оперативной памяти.

image

image

Что же касается основных рабочих инструментов в этом проекте, Elixir и Phoenix Framework, у меня есть все основания полагать, что в ближайшие годы они станут такими же популярными, как в свое время Ruby и Rails, так что есть смысл начинать их освоение уже сейчас.
Спасибо за внимание!

Ссылки


Разработка:
elixir-lang.org
phoenixframework.org
Нагрузочное тестирование:
gatling.io
flood.io
Мониторинг:
prometheus.io
grafana.com
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 58
  • 0
    спасибо за статью, всегда интересно читать про использование вебсокетов =) я тоже как-то давно развлекался поднятием 1кк коннектов на домашнем компе, выдерживало 800к, сообщения ходили, все было ок, старенький amd на 4 ядра и 16гб оперативы, java. Тестировать это было интересно, пришлось поднять 20 виртуалок по 40к коннектов
    • 0
      как получил 40к коннектов? почему именно 40к? что за сервер?
      если на одном сервере сделать 20 http портов слушающих ws и на каждом по 40к коннектов?
      это вместо 20 виртуалок.
      • 0

        Ну всего лимит 65к коннектов с одного клиента в один порт, минус занятые файловые дескрипторы, можно и с одного клиента 1кк коннектов открыть, если в разные порты и лимиты настроить, но про разные порты я не подумал, а с лимитами в lxc было что-то мутно. Кстати как балансировать 20 разных портов?

        • 0
          про разные порты — мысль пришла из твоего опыта. вот тут tootallnate.github.io/Java-WebSocket это вполне можно реализовать, там просто «слушатель» порта. он отдельно. а вот если использовать либу из tomcat — там так просто порты не добавить…
          как балансировать по портам — чисто теоретически — массив — свободных, при подключении/открытии страницы брать из него свободный и подставлять… и убирать из массива…
          для начала как бы проверить вообще такую возможность — несколько http портов вместо машин.
          и вроде для ws подключений нет ограничений для количества портов. они вроде как отдельно от портов http? ( имеется в виду все 65к)
          • 0
            ws идет поверх http, для балансировки нужно будет как-то сообщать клиенту в какой порт стучаться, но да, всё реализуемо
            • 0
              если клиент браузер — то всё просто, а если приложение — то несколько усложняется.
    • +1
      Спасибо и за пример и за реальную статистику. Чисто теоретически я вобщем-то был уверен в том что решения на основе Erlang это наиболее удачное решение для веб-сокетов. То что Go показал сравнимую производительность в тестах это еще не гарантирует сравнимую производительность на проде (и не исключает ее). Хотелось бы посмотреть на реальную статистику реальных приложений на Go, если она у кого-нибудь имеется.
      • 0
        habrahabr.ru/company/mailru/blog/331784 к примеру.

        Да и как раз на проде сложно представить реальную задачу, где Erlang составил бы сильную конкуренцию Go. Разве что какие очень развесистые деревья или подобные структуры.
        • 0
          Спасибо интересная статья. Правда как я понял из контекста это все же не работет на продакшине, а то что работает (как я понял тоже Go только без оптимизации) нет конкретной статистики. Про erlang конкретно я имел в виду исключительно решение с большим количеством сокетов. (см. phoenixframework.org/blog/the-road-to-2-million-websocket-connections ).
          • 0
            Как раз таки работает.
            Но в любом случае такие технические статьи на любом ЯП интересно почитать.
      • +1
        А какая версия Go была и что было в GOMAXPROCS?
        • +2
          Ни ссылок на golang в конце, ни тестируемого кода, ни даже в тегах не упомянут) Похоже, что Go, в контексте статьи, это просто как в рекламе:

        • 0

          Была ли проверка с mnesia in memory в качестве базы данных на отдельной ноде? Теоретически это позволило бы мониторить упавшую ноду и обновлять цифры.

          • +4
            много обовсем,

            Тесты проводились на примере простейших чатов на Go и Phoenix


            мне, например, непонятно что за такие простейшие чаты и откуда,

            хороший тон: публиковать тестируемый код, иначе остается словам верить.
          • +2
            Для 3х сценариев ( 1)-минимум подключенных клиентов (например два), (2)-среднее кол-во (например 150К и (3) тестируемый макс — например 800к) сл. вопросы:

            — Скольку удавалось получить new-connections-per-second (создание нового соединения — процесс очень дорогой)
            — Какая messages-per-second
            — Какое latency при передаче сообщения клиент-клиент
            — Какое время регистрации нового клиента

            • 0
              Отвечу вам цифрами с нашего последнего нагрузочного тестирования на уже готово продукте.

              Порядка 220 новых соединений в секунду, 200к ботов.
              Время регистрации нового клиента не превышает 50ms.
              В пике около 6000 сообщений в секунду летает между сервером и клиентами.
              У нас бизнес логика не предполагает общения клиент-клиент, NDA не позволит дать конкретики, абстрактно схема следующая:
              1. Событие на сервере -> Уникальные сообщения для большой группы пользователей
              2. Реакция пользователя -> Сообщение серверу о том что пользователь подтвердил получение сообщения 1
            • –2
              Ого, вот это у вас темп работы — разработка за месяц сервиса для 150 тыс. людей онлайн — круто!

              Вот интересно, вы, как Тимлид проекта, когда выбирали Элексир vs Go — рассматривали ли вопрос кадров? Кажестся, что у нас куда проще найти Go-разработчика, чем Erlang/Elixir.
              • +5
                Код nodejs сервера, который у вас не выдержал 5000 соединений в студию на гитхаб!
                • 0
                  Ну уж раз так то список сайтов на node.js где это работет на 150 тыс. соединенй (хотя бы ) тута же.
                  • 0
                    Я не утверждаю, что 150 000 соединений невозможны или возможны. Автор статьи же наоборот утверждает, что 5000 невозможно.
                    Кстати, случайно не подскажете где ссылка на сайт автора в продакшене?
                    • 0
                      Далее я рассмотрел Node.JS WS. Этот фреймворк показал неплохие результаты – около 5 тысяч коннектов на тестовом стенде без дополнительных настроек

                      Возможно 5000. Ссылки на сайт автора у меня нет.

                      По поводу использования конерктно nodе.js и конерктно для веб-сокетов очень большие вопросы есть. Если бы был реальный пример то можно было бы пробовать реализовать в нагруженном (хотя бы) проекте.
                      • 0
                        Вот тут автор уверяет, что еще в 2015 поднял на node.js на амазоновском EC2 600-620к вебсокет соединений. Пусть и с небольшими подпорками, но, видимо, реально.

                        Сам я в ноде практически 0, так что хз.
                        • 0
                          Вобщем-то автор не скрывает что это были лишь тесты со «своим клиентом». Цель была присоединиться и держать соединение на что не использщуется основной процесс в коором віполняется JavaScript а только средства NIO. Что будет когда все эти коннеты «заговорят» и потребуют свою долю от движка JavaScript. Большой плюс автора обсуждаемй статьи на Хабре это то что он сделал реальное приложение и показал нам графики реальной загрузки реальной конфигураци сервера.

                          wouter
                          April 13, 2015 at 20:37 /

                          What did you use to generate 620k connections?
                          And did you send a message over every connection every x seconds or was is just a silent connection?

                          Daniel Kleveros
                          April 14, 2015 at 08:11 /

                          I created my own client with the same websocket lib websockets/ws which I then deployed on a cluster of M1.Large instances.

                          It was silent connections but to keep the connections alive, if you are behind a elastic load balancer, you need to check the idletimeout setting on the loadbalancer and send a ping before that time expires. If not the load balancer will start to drop your connections.
                        • 0
                          Около 5000 это может и меньше. Конкретики как всегда около 0. Вот я и задал вопрос. Ответа тоже около 0. NDA видимо)

                          Все больше склоняюсь к тому, что автор статьи лукавит. Вот почему: конфиг который он скинул – кривой косой, отсутствуют примеры кода, тулза под названием artillery выдает не очень полезную инфу.
                          Скорее всего человек просто получил задачу написать статью. Кое-как сделал, накидал и вот уже на хабре. Все вопросы можно игнорировать сославшись на NDA. Спрашивается, зачем писать статью если нет возможности рассказать полностью…

                          Давайте загуглим эту конторку под названием mediasoft.
                          Вот она http://php73.ru/.
                          А это favicon этого сайта:
                          image
                          Хотел найти список сотрудников там, но не нашел. То ли конфиденциальность такая, то ли лень, то ли текучка кадров лютая… Непонятно. Зато есть список выполненных работ, где числится carprice. Ну вот, хоть заценю этот сайт и гляну как вебсокеты работают там. Честно говоря спустя 5 минут так и не нашел где там вебсокеты. Попытался купить авто, но мне просто открывалась еще одна такая же вкладка браузера. Простой php сайт на битриксе?

                          Всё это очень мутно выглядит, что даже не хочется дальше разбираться. Ну не смогли на js 100к коннектов сделать да и пофиг.

                          напоследок фото топикстартера
                          image

                          ладно, еще одно фото
                          image

                          конфиг
                          config:
                            target: "http://localhost:3000"
                            socketio:
                                transports: ["websocket"]
                            phases:
                              - duration: 1
                                arrivalRate: 2
                          scenarios:
                            - engine: "socketio"
                              flow:
                                - think: 1
                          
                          
                          
                          


                          результат
                          Started phase 0, duration: 1s @ 22:50:07(+0600) 2018-03-15
                          Report @ 22:50:10(+0600) 2018-03-15
                          Scenarios launched: 2
                          Scenarios completed: 2
                          Requests completed: 0
                          RPS sent: NaN
                          Request latency:
                          min: NaN
                          max: NaN
                          median: NaN
                          p95: NaN
                          p99: NaN

                          All virtual users finished
                          Summary report @ 22:50:10(+0600) 2018-03-15
                          Scenarios launched: 2
                          Scenarios completed: 2
                          Requests completed: 0
                          RPS sent: NaN
                          Request latency:
                          min: NaN
                          max: NaN
                          median: NaN
                          p95: NaN
                          p99: NaN
                          Scenario counts:
                          0: 2 (100%)



                          незатейливый backend
                          var app = require('express')();
                          var http = require('http').Server(app);
                          var io = require('socket.io')(http);
                          var port = process.env.PORT || 3000;
                          
                          io.on('connection', function (socket) {
                              console.log("connected");
                              socket.on('hello', function (msg) {
                                  console.log("hello");
                                  io.emit('hello', msg);
                              });
                          });
                          
                          http.listen(port, function () {
                              console.log('listening on *:' + port);
                          });
                          

                  • 0

                    не холивара ради, простое любопытство: почему не СИ?
                    я набросал работающий фреймворк за день. но у меня уже было понимание, как устроен протокол. разобрался когда пытался, несколько лет назад, делать сервер на CLI PHP.

                    • +1
                      Потому что нет готовых инструментов, зато есть ограничения по времени и уровню поддержки.
                      • 0
                        Почему не C — надеюсь автор ответит.
                        А вот работающие «фреймворки» давно написаны и вряд ли можно написать что-то более производительное, чем связка libwebsocket и libevent.
                        • 0
                          Были мысли и про СИ, остановило отсутствие готовых инструментов, общая сложность разработки и то что СИ, в целом, не особо ориентирован на WEB.
                          • 0
                            мне кажется, вы как-то через-чур преувеличиваете сложность СИ, не так страшен чёрт как его малюют. пишете некое CORE (ядро) для общей обработки Websockets, а для разных функций — разные подключаемые DLL модули. и не придётся перекомпилять всё то и дело.
                            а вообще, я уверен, что-то уже есть. вот люди советуют вам посмотреть libwebsocket и libevent, посмотрите, хотябы и обзорно. хотябы и после того, как «горящий» проект сдадите в прод. я думаю такие вещи имеют высокую повторяемость в потребности, и время на изучение, проработку вопроса не будет потрачено без пользы. оно себя с лихвой окупит в будущем.
                            • +1
                              Проект уже давно ушёл в прод, и успешно выполняет задачи.
                              В мир C/C++ обязательно загляну в свободное время. Но «продать» заказчику реализацию на С, по моему мнению, будет ещё сложнее чем на Erlang. Увы, все хотят дешёвых и популярных технологий, таких как PHP, Ruby, Pyton
                        • 0
                          В сторону Tornado (Pyhon) не смортели?
                          • 0
                            А как же Java + Spring?
                            • 0

                              Приветствую всех!
                              Ws действительно интересная тема. Недавно была задача для crm-bpm системы сделать event-сервер. Я остановился на node.js. У меня, служба работающая под pm2, является клиентом ws для asterisk. Ловит и обрабатывает все события АТС и раздает авторизованным пользователям системы, подключенным по wss, уведомления о входящих звонках, проверяя соответствия номера клиента с наличием в базе данных. Также от пользователей приходят комманды на уведомления других пользователей при постановке задачи, состояние он-лайн, офф-лайг, а также работа по API с сайтами при поступлении POST запросов. То есть, одновременно это клиент и сервер.
                              Пользователей он-лайн около 200, события от АТС идут постоянно (один только звонок порождает около 6000 тыс. строк), их около 400 в день. С сайтов приходят запросы, но немного, один-два в час.
                              Так к чему я это все рассказывал. Честно говоря не могу понять как протестировать нагрузку, чтобы можно было смело говорить о каких-то конкретных цифрах.
                              Я конечно понимаю, что видимо знаний мало, но тут и запросы к базе и активность клиентов системы очень варьируется, и данные по API разный объем имеют. Плюс-минус километр если, то на 200 пользователей при 400 звонках в день и 300 задачах в системе + 40 отправленных сообщений по API в сутки, пиковая нагрузка по RAM была 81mb. По процессору не более 10%. Можно смело об этом говорить, что эти показатели не превышались никогда, так как PM2 в этом случае перезапускал бы службу (ну должен это делать во всяком случае) и фиксировал это событие.
                              Интересно было бы узнать о каких-то системах расчета нагрузки, потому как мои средние наблюдения и "простые чаты" это как-то из разряда средней температуры по больнице…
                              За статью спасибо! Я, к сожалению до Go не дошел в этом вопросе, а PHP отмел по причине неудобной, ИМХО реализации по работе с сокета и.

                              • –1
                                Так много вариантов со стороны PHP (не совсем очевидного выбора о котором думают в первую очередь говоря о вебсокетах), а со стороны node.js один только ws. Хотя можно было ещё и socket.io рассмотреть — было бы интересно посмотреть на его результаты.
                                • 0
                                  socket.io — смотрел, пробовал. Это было чуть раньше, когда он был незаменим в связи со слабой поддержкой сокетов браузерами. Сейчас все и так хорошо.
                                  Сам большой поклонник PHP, но сдался в связи в удобством реализации на Node.
                                  Могу сказать только что socket.io многократно больше потребляет траффика… или я «котов не умею готовить» :)
                                  • 0
                                    т. Плюс-минус километр если, то на 200 пользователей при 400 звонках в день и 300 задачах в системе + 40 отправленных сообщений по API в сутки, пиковая нагрузка по RAM была 81mb
                                    На ноде такая загрузка была? Конечно одновременных 200 соединений это почти ничего но все равно я предполагал большую цифру.
                                    • 0
                                      Давайте в скайп, что тут флеймить: akadex2
                                      :)
                                • 0
                                  хотелось ты посмотреть код на NodeJS, почему был такой маленький лимит у вас в запросах
                                  • 0
                                    Поверьте, вот все по мануалу из:
                                    www.npmjs.com/package/ws
                                    Там банальный небольшой скрипт процедурный. Никакого специализированного фреймворка. Все время/трудозатраты в основном на тесты и отладку ушли. Те же event`ы различных диалпланов Астериска парсить. А лимиты такие сугубо из показателей мониторинга. Как только PM2 начнет ребутить, то будет повод посмотреть логи, подумать о том, что надо ресурсы увеличить, или увидеть очередной объект, который надо за`delete`ить.
                                    • 0
                                      ws лучше вообще не использовать, где хотя бы более 1000 коннектов предполагается.
                                      Есть другая библиотека — uws (на С++). Производительность и расход ресурсов различается в несколько раз. Особенно момент массового подключения клиентов и если много данных передавать.
                                      • 0
                                        Для браузера пока что есть альтернатива веб-сокеты или fallback на еще более реурсоемкие технологии. Если есть другие варианты расскажите о них, пожалуйста. По поводу библиотеки uws (на С++) какую нагрузку в Ваших проектах она выдерживает и какие ресурси при этом требует?
                                        • 0
                                          В основном использовалось для рассылки событий клиентам, в разных проектах. На один процесс обычно получалось по 3k коннектов и в среднем 100-150 ГБ трафика за месяц, хотя это и не особо важно. Примерно год назад (когда библиотека была молодая и сыроватая) было сравнение на нодах Digital Ocean (512-1024 МБ). Выйгрыш по памяти выходил до 4-5 раз (кол-во клиентов до OOM killer), а так же сравнимо CPU. Исчезла проблема, когда в момент наплыва клиентов (после рестарта) происходил ступор процесса на несколько минут.
                                          График (производительности) на Github соответствует заявленным цифрам, есть другие обзоры.
                                          Интерфейс библиотеки совместим с пакетом ws, socket.io/engine.io/… поддерживают замену пакета. Единственный минус — необходимо компиляция.

                                          www.npmjs.com/package/uws
                                          github.com/uNetworking/uWebSockets
                                          • 0
                                            Спасибо хороший там график производительности и много альтернативных игроков показана производительность. Основной вопрос который все же меня лично волнует — это нужен ли сейчас fallback. При этом с учетом не только возможностей браузера которые конечно сейчас все поддерживают веб-сокеты. А с точки зрения не недоступности сокетов в некоторых странах (якобы они подпадают под действие закона об ограничении), в сетях некторых мобильных операторов.
                                    • 0
                                      Если посмотреть на код можно наверное сказать почему был лимит 5000. Но это не ответит на вопрос какой может быть реальный лимит и какие при этом будут затраты (сколько ядер, сколько памяти, сколько нодов. У Вас есть реаьные данные по nodejs как у атора этой статьи есть реальные данные по фениксу? Расскажите, это интересно.
                                      • 0
                                        у меня есть проект в проде, и там показатели в разы выше
                                        вот и хотел код глянуть

                                        с фениксом не работал, тут нечего сказать
                                        интерес исключительно по NodeJS

                                        по готовым примерам… вот готовый модуль, лаботающий на сокетах, использующий нативный модуль
                                        www.npmjs.com/package/ipc-socket

                                        максимальный лимит который был достигнут на моей машине, 35к/сек
                                        этот модуль у нас так же используется в проде, по нему гоняем логи с нескольких проектов в единое хранилище
                                        • 0
                                          То есть у Вас одновременно около 1 миллиона одновременно подключившихся активных клиентов? Икакие при этом параметры по серверу/серверам (количество серверов/ядер/объем памяти)?
                                          • 0
                                            на серверах замеры не производил
                                            замерял только на своей локальной машине
                                            замер производился на конфигурации
                                            i7
                                            16G RAM

                                            у имеющихся двух серверов, только оперативы в 2 раза больше, остальные параметры примерно те же
                                            • 0
                                              Ага у Вас свой нативный модуль. А как с fallback если веб-скоеті на поддерживаются и актуальнно ли сейчас делать fallback? Говорят что например в некоторых странах (Китай) и некоторые провайдеры (мобилного интернета) эти веб-сокеты не поддерживают. Также поддержка веб-сокетов из соображений скажем безопасности моет быть отключна администраторами корпоративной сети для доступа к внешним сверерам/сайтам.
                                              • 0
                                                этот модуль рассчитан только на работу в серверном коде
                                                а там TCP сокеты никто никогда не отменял
                                                • 0
                                                  А какой модуль работет с 1 млн. одновременных клиентов-браузеров онлайн? Мы же насколько я понял это сейчас обсуждаем?
                                                  • 0
                                                    изначально, я у автора просто спросил код, и ничего обсуждать не собирался

                                                    написание кода под высокие нагрузки, имхо, это вопрос прямизны рук
                                                • 0
                                                  Также поддержка веб-сокетов из соображений скажем безопасности моет быть отключна администраторами корпоративной сети для доступа к внешним сверерам/сайтам.


                                                  не слышал ни одного такого случая
                                                  если что-то закрывается с целью безопасности, то уже сразу целым доменом/IP
                                        • 0
                                          Я наконец понял в чем Ваш вопрос. Автор не говорит что у него было 5000 запрсов в секунду. И для вебсокетов (не в серверном варианте) высокая нагрузка совсем другое подразумевает. Это когда у Вас 5 или 150 тысяч одновременно пользователей открыли соединения из браузера и все они работают не секунду а час или например цеоый день у них приложение открыто и нужно держать постоянно соединение. Я-то думаю откуда у Вас на ноде такие показатели на слабых девайсах.

                                          Или если перейти на серверы то это у вас со всего мира 150 000 серверов к Вами присоединились и держат коннекты. А если у Вас пусть даже миллион сообщений в секунду но от сотни серверов то это как раз сто содеинений а не сто миллионов соединений.
                                        • 0
                                          И это ещё cowboy версии 1. Жду не дождусь, когда cowboy 2 интегрируют в феникс.
                                          Есть сторонний хэндлер для cowboy 2: github.com/voicelayer/phoenix_cowboy2.
                                          Было бы интересно взглянуть на графики из статьи ещё раз, но уже с cowboy 2
                                          • 0
                                            Причитал статью и вспомнил высказывание: "- Вы не любите котов!? — Вы просто не умеете их правильно готовить!"

                                            Как чужой опыт, статья конечно имеет право быть, но ИМХО выглядит она как хвалебная песня в честь Linux, Go и Erlang.
                                            Можно было просто сказать, что наша команда знает Linux, Go и Erlang и поэтому в условиях дефицита времени для достижения цели выбрали в качестве инструмента, то что мы лучше всего знаем. (И это единственно правильное решение).

                                            Но недостатки других решений или преимущества (Linux, Go и Erlang) совсем не очевидны.
                                            Чем плох PHP и в частности PHP Workerman не понятно!

                                            «Poll vs. Epoll»… А где kqueue/kevent?
                                            Или kqueue настолько не эфективен что не заслужил упоминания? Да,… не кросплатформенно… да, с этим умеют работать только BSD системы и некоторые комерческие системы используют подобный подход.
                                            Но согласитесь, что это проблема Linux, а не PHP Workerman!
                                            NGINX + PHP-FPM умеют использовать эфективный kqueue и вместе они прекрасно масштабируются «по самое не могу»!

                                            «PHP Workerman — Код находится на уровне PHP 5.3 и не соответствует никаким стандартам.» — простите, а каким конкретно стандартам он должен соответствовать?!
                                            У меня код работал на PHP 7.1, но если автор тестировал на сервере с PHP 5.3, то это даже не проблема настроек PHP… и уж тем более не проблема PHP Workerman. И из этого не следует, что он не позволяет реализовывать высоконагруженные проекты…

                                            Скажем прямо, просто Вы выбрали другой путь… свой путь.
                                            • 0
                                              У меня код работал на PHP 7.1

                                              Не сочтите за наезд. Я просто реально хочу получить реальные данные о реальных серверах (как у автора этой статьи). Какая нагрузка была на приложение? Какие были затраты по памяти/процессорам? Как мониторилась доступнасть веркеров? Сколько было запущено веркеров? Каки были организованы сессии в смысле как отслеживалось чтобы лиибо было соединение с одинм и тем же веркером или же данные расшарвались между веркерами? Расскажите. Это интересно.
                                              • 0
                                                Можно было просто сказать, что наша команда знает Linux, Go и Erlang

                                                Это было-бы великолепно, но увы это был первый опыт работы с Elixir

                                                А где kqueue/kevent?

                                                Нельзя объять необъятное, BSD системы не рассматривали, хотя возможно стоило

                                                а каким конкретно стандартам он должен соответствовать

                                                Ну для начала PSR

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое