Воркер (worker) — дочерний процесс или поток, которому мастер-процесс веб-сервера или сервера приложений делегирует обработку входящих запросов. Каждый воркер берёт один запрос из очереди и обрабатывает его независимо от других. Пока воркер занят, следующий запрос ждёт или достаётся другому свободному воркеру.
Модели воркеров
Существуют три основные модели параллелизма для веб-серверов:
- Prefork (многопроцессная)
- Мастер-процесс форкает N дочерних процессов при старте. Каждый процесс обслуживает одно соединение. Изолирован от других — утечка памяти в одном не влияет на остальные. Apache MPM prefork, PHP-FPM в режиме pm=static. Потребляет много RAM при большом числе воркеров.
- Threaded (многопоточная)
- Один процесс, несколько потоков. Потоки разделяют память — дешевле, чем процессы. Требует потокобезопасности кода. Gunicorn gthread, Java/Tomcat.
- Event/async (событийная)
- Один воркер обслуживает тысячи соединений через неблокирующий I/O. Nginx (event-driven), Node.js (single-threaded event loop). Эффективен при долгих I/O-ожиданиях, но плохо подходит для CPU-тяжёлых задач.
Сколько воркеров нужно
Правило для CPU-bound приложений (вычисления): число воркеров = числу ядер CPU. Для I/O-bound приложений (ожидание БД, сети): Gunicorn рекомендует (2 * CPU) + 1. Например, на сервере с 4 ядрами — 9 воркеров. Для Nginx оптимально worker_processes auto — определяет по числу ядер автоматически. Для PHP-FPM важно учитывать потребление RAM одним процессом PHP: если воркер потребляет 50 МБ, а доступно 2 ГБ — максимум ~40 воркеров.
# nginx.conf:
worker_processes auto;
worker_connections 1024;
# PHP-FPM (pm=dynamic):
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
История
Модель воркеров появилась с ростом нагрузки на веб-серверы в конце 1990-х. Apache 1.x использовал prefork — по одному процессу на запрос. В 2004 году вышел nginx с event-driven архитектурой: один воркер обслуживает тысячи соединений через epoll/kqueue. В 2000-х появились серверы приложений (Gunicorn, uWSGI, Puma), стандартизировавшие интерфейс WSGI/Rack для Python и Ruby с моделью нескольких воркер-процессов.
Воркеры в контексте хостинга
На виртуальном хостинге число воркеров PHP-FPM ограничено тарифом. На VDS и выделенных серверах настраивается вручную. При нехватке воркеров запросы накапливаются в очереди и пользователи видят задержки. При избытке воркеров — сервер упирается в RAM и начинает использовать своп, что ещё хуже.
Воркеры в разных технологических стеках
Python (Gunicorn): воркеры типа sync — один поток на воркер, подходит для CPU-bound; gevent/eventlet — асинхронные воркеры для I/O-bound. Рекомендация Gunicorn: (2 × $num_cores) + 1 воркеров. Celery worker — отдельные процессы для фоновых задач (очереди), не путать с HTTP-воркерами. PHP-FPM пулы: pm.max_children = максимум воркеров, pm.start_servers = при старте, pm.min_spare_servers/pm.max_spare_servers — динамическая регулировка.
Node.js Cluster: один master-процесс + N worker-процессов (по числу CPU). PM2 управляет cluster mode: pm2 start app.js -i max. В отличие от Python/PHP, Node.js воркеры делят event loop — не нужен prefork. Nginx worker_processes auto = число CPU-ядер; worker_connections = 1024 (на воркер). Итого: max connections = worker_processes × worker_connections.
На что обращать внимание
Воркеры — не потоки. В PHP-FPM каждый воркер полностью изолирован: переменные, состояние OPcache и подключения к БД не разделяются. Подключения к PostgreSQL или MySQL создаются заново каждым воркером — для высоконагруженных сайтов нужен пул соединений (PgBouncer, ProxySQL). Мониторинг воркеров: php-fpm status page, nginx status, метрики process_count в Prometheus.