Рабочие процессы в асинхронных серверах

Question

[Runcorn]

Здравствуйте.

Не могу до конца разобраться с такой темой, как рабочие процессы (workers) в асинхронных серверах. Зачем они нужны и есть ли в них смысл?
Например, в nginx рабочие процессы являются нормальным явлением: nginx.org/ru/docs/ngx_core_module.html#worker_processes
В lighttpd их не советуют использовать: redmine.lighttpd.net/projects/1/wiki/Docs_MultiPro...

1. Нужны ли они на самом деле?
2. И вопрос к тем, кто занимался разработкою асинхронных серверов с воркерами или разбирался с ними: как все это реализовано на низком уровне? Принимается подключение (accept) из главного процесса и потом как то передается одному из дочерних воркеров или же все воркеры одновременно слушают сокет?

Answer 1

[Сергей Протько]

если на низком уровне то все просто. Главный процесс слушает сокет и делает accept. Затем есть 2 варианта: мультиплексировать запросы (из массива выбирать сокеты готовые для чтения через select/epoll и делать recv или accept в зависимости от того что за сокет готов предоставить данные) либо запихнуть обработку сокета в отедельный поток/процесс. Процессы надежнее ибо если он упадет то серверу от этого ничего не сделается.

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

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

вообще погуглите про проблему 10k, можно нагуглить кучу алгоритмов обработки запросов.

А что касается lighttpd то в документации описаны случаи когда нужно использовать многопроцессорность, и приведены возможные проблемы с модулями. Именно советов "не использовать" там нету.

Answer 2

[Ilya Evseev]

Смысл есть, т.к. по умолчанию асинхронное приложение работает в одном потоке, т.е. может загрузить не более одного процессорного ядра.
Если одного ядра мало и\или есть риск, что в потоке возникнет долгая операция - увеличивайте количество воркеров.
В Лайти многопоточный режим отлажен менее тщательно, поэтому предупреждают.
В Nginx'e проблем нет, ставьте "auto".

Answer 3

[AxisPod]

Основной смысл в том, что обработка ведется на основе событийной модели. Для этого используются epoll/kqueue и подобные решения в зависимости от ОС. Далее используется не одна очередь, в этом случае без использования потоков использовалось бы только одно ядро, что неправильно (именно поэтому хорошо сливают библиотеки libuv (разрабатывается для node.js), libevent и подобные). Для того чтобы полностью использовать все ядра процессора и запускается по одному процессу на ядро. По идее можно было бы использовать и многопоточность, но в этом случае потребуется синхронизация, а она в свою очередь негативно скажется на производительности.