← Back to blog

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

Feb, 21, 2026

#nginx#architecture#checkpoint#performance

⚙️ Теория

🎯 Цель дня

В этот день ничего нового не изучаем.
Задача: собрать уже изученные части в единую архитектурную модель.

🧩 Что нужно сделать

Нарисовать на листе 4 слоя:

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

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

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

✍️ Письменные ответы (обязательно)

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

Потому что меняется URI (а иногда и контекст обработки), значит старый location может быть уже неверным.
NGINX делает новый location lookup и запускает фазовый проход заново для нового маршрута.

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

  • accept-конкуренция между worker (в зависимости от accept_mutex/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: 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-файлов;
  • рост I/O и времени обработки запроса;
  • влияние на память и диск в зависимости от buffering-настроек.

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

Ожидаемо:

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

✅ Критерий Level 1

Если вы можете заранее (до запуска теста) объяснить направление изменений по:

  • throughput;
  • latency;
  • CPU;
  • active connections;
  • ошибкам и таймаутам,

значит архитектурная модель уже собрана и вы на Level 1.

🧪 Практика

  • Используйте команды и примеры из разделов выше как рабочий чеклист.
  • Перед применением в production валидируйте изменения на test/stage и сверяйте с официальной документацией.

🧾 Вывод

Материал резюмирует ключевые принципы и практики по теме статьи. Для production-решений опирайтесь на ограничения вашей инфраструктуры и официальные источники.

📚 Ссылки

  • См. ссылки в секции Проверка источников ниже.

✅ Проверка источников

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