← Back to notes

NGINX: Сбор архитектурной
модели (Level 1)

2026-02-21

#checkpoint

Архитектурные слои

Нарисовать четыре слоя на одной схеме:

  • процессная модель (master/worker);
  • event loop (sleep/wakeup, I/O ready);
  • lifecycle запроса (от accept до keepalive/close);
  • shared state (per-worker vs shared).

Минимум на схеме:

  • входящий сокет;
  • epoll_wait;
  • phase engine;
  • upstream;
  • shared zones и mutex/atomic-path.

Письменные ответы

Почему internal redirect перезапускает phase engine?

Меняется URI и контекст обработки, старый location может быть уже неверным. NGINX делает новый location lookup и запускает фазовый проход заново. В rewrite-модуле цикл ограничен 10 итерациями, после чего возвращается 500.

Где есть блокировки?

  • accept-конкуренция между worker (accept_mutex по умолчанию off, reuseport);
  • shared memory зоны (limit_req, limit_conn, ssl session cache, upstream zone);
  • mutex/atomic-path внутри общих структур (slab, rbtree, counters).

Что произойдёт при slow client?

Ответ отправляется медленно, request живёт дольше, растут active connections и занятые буферы. При большом числе slow clients можно упереться в worker_connections (по умолчанию 512): worker перестанет принимать часть новых соединений даже при умеренном CPU.

Почему memory pool уничтожается целиком?

Большинство объектов живут столько же, сколько request. Один destroy pool вместо множества malloc/free, меньше фрагментация и накладные расходы.

Сценарии и предсказание поведения

1. 10k RPS + медленный upstream

  • растёт latency (особенно p95/p99);
  • увеличивается число активных соединений;
  • throughput перестаёт расти линейно;
  • возможны upstream timed out, 502/504.

2. burst 100k req/s

  • пики в очередях/лимитерах;
  • рост lock contention в shared state;
  • рост ошибок от лимитов/таймаутов;
  • CPU растёт быстрее полезного RPS.

3. 10MB request body

  • активное использование client_body_buffer_size и temp-файлов (при client_max_body_size выше дефолтного 1m);
  • рост I/O и времени обработки;
  • влияние на память и диск зависит от buffering-настроек.

4. отключённый keepalive

  • больше accept() и TCP/TLS handshakes;
  • выше CPU на ту же полезную нагрузку;
  • ниже RPS при тех же ресурсах;
  • больше короткоживущих соединений (TIME_WAIT).

Критерий Level 1

До запуска теста объяснить направление изменений по: throughput, latency, CPU, active connections, ошибкам и таймаутам.

Ссылки

NGINX: Сбор архитектурной модели (Level 1) | Aleksandr Suprun