Устойчивость веб-сервера к высокой скорости опроса клиентов: веб-серверы Cowboy против Yaws

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

Каждый клиент обращается к веб-серверу каждые, скажем, 2 секунды (это довольно высокий показатель). Когда события доступны, они отправляются в формате JSON клиенту JavaScript. Теперь для этого требуется настройка сервера для обработки большого количества кратковременных соединений. Я реализовал одну такую ​​систему с помощью веб-сервера Yaws. Однако, поскольку Yaws запускает довольно много других служб, он кажется тяжелым, и соединения начинают либо отклоняться, либо прерываться, когда они превышают 30 000 (возможно, потому, что я запускаю некоторые таблицы ETS на той же виртуальной машине Erlang, на которой работает Yaws). для их разделения может потребоваться rpc:call/4, что, боюсь, увеличит задержку]). Я знаю, что есть определенные настройки операционной системы, и они были сделаны.

Это не было бы проблемой, если бы можно было легко объединить несколько экземпляров Yaws в кластер. В Yaws я использую несколько модов приложений и делаю вещи RESTful. Я подумал, что веб-сервер Cowboy может немного улучшить ситуацию. Раньше я не использовал Ковбой, но я использовал Мисультин. Глядя на Cowboy, это полноценное OTP-приложение, и кажется, что его легко кластеризовать, а из-за легкости оно, возможно, может увеличить количество клиентов, которые может обрабатывать вся система. Хранилище находится в Mnesia, которую я могу легко распределить, чтобы добавить больше узлов (возможно, путем репликации), чтобы перед каждым экземпляром Mnesia был экземпляр Cowboy.

Мои вопросы:

  1. Верно ли мое предположение, что если я перейду с Yaws на Cowboy, я могу значительно повысить производительность?

  2. Yaws имеет чистый API через Appmods и запись #arg{}. Есть ли у Ковбоя эквивалент этих двух вещей (проиллюстрируйте, пожалуйста)?

  3. Может ли Cowboy обрабатывать загрузку файлов? Если да, то какой сервер (Yaws или Cowboy), на ваш взгляд, лучше использовать в случае частой загрузки файлов? Проиллюстрируйте, как выполняется загрузка файлов с помощью Cowboy.

  4. На одном компьютере можно запустить несколько экземпляров Yaws. Как вы думаете, поможет ли создание множества экземпляров Yaws на сервер (физический блок) и распределение клиентской нагрузки между ними? Что мне нужно знать об этом?

  5. Когда я устанавливаю yaws.conf параметр max_connections = nolimit, как мне указать то же самое в Cowboy?

Теперь я следил за интервью с автором Cowboy, и он обсуждает причины, по которым Cowboy легче, чем Yaws. Он говорит, что

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

Поскольку Cowboy использует библиотеку пула слушателей Ranch, каким-то образом в результате получается более высокая способность обрабатывать больше подключений. плюс использование бинарников, а не списков.

Еще цитата из того же интервью:

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

Интересно, как yaws справляется с этим случаем. Почему-то мой проблемный домен нуждается в облегченной обработке HTTP. На самом деле верно то, что Yaws приведет к большему потреблению памяти по сравнению, скажем, с Mochiweb, Misultin или Cowboy. Меня больше всего беспокоит то, что Yaws имеет лучший/самый чистый API, благодаря чему он дает нам доступ к #arg{}, содержащему все, что нам нужно, в виде записи Erlang, чтобы мы могли получить их сами, чем другие, которые имеют множество функций для извлечения материала извне. Даже документация: документы Yaws довольно хороши и понятны. Возможно, мне нужно посмотреть больше кода Cowboy для таких вещей, как загрузка файлов и простая обработка запросов GET и POST.

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


person Muzaaya Joshua    schedule 15.10.2012    source источник
comment
Голосование против должно сопровождаться reason. Каждый вопрос, требующий других мнений, отвергается. Интересно, в чем причина? Кто-нибудь объяснит, почему за этот вопрос проголосовали против. Если у вас нет ответа, почему бы не beat it покинуть эту страницу? ха?   -  person Muzaaya Joshua    schedule 15.10.2012
comment
Я не понимаю эту часть того, что вы написали: ... yaws запускает довольно много других сервисов ... Насколько я вижу, Yaws регистрирует 8 процессов, включая своих супервизоров, регистратор и т. Д. Это для меня делает не может квалифицироваться как целый ряд многих других услуг.   -  person Steve Vinoski    schedule 15.10.2012
comment
Можете ли вы объяснить, какие проблемы у вас возникают при кластеризации экземпляров yaws?   -  person Steve Vinoski    schedule 15.10.2012
comment
я сделал некоторые правки. Спасибо @Виноски   -  person Muzaaya Joshua    schedule 15.10.2012
comment
Вы можете попробовать новую функцию пользовательской отправки Yaws. Вы поставляете модуль диспетчера с функцией dispatch/1. Он получает запись #arg{}, как и appmod, но вы сами обрабатываете запись ответа на сокет. Подробнее см. эту фиксацию. В качестве альтернативы можно добавить тестовый пример в список рассылки Yaws, чтобы мы могли взглянуть на это.   -  person Steve Vinoski    schedule 15.10.2012


Ответы (1)


Ваш предел в 30 000 отказов звучит очень похоже на предел в 32 000 где-то. Либо количество процессов по умолчанию, равное 32 КБ, либо какое-то системное ограничение на файловые дескрипторы и так далее. Вы не должны исключать возможность того, что ограничение связано с ядром. Я видел, как системы довольно легко достигают своих пределов из-за конфигураций ядра, с которыми может быть очень сложно справиться.

person I GIVE CRAP ANSWERS    schedule 18.10.2012