Ось урок, створений спеціально для вас у стилі David Malan: енергійний, з живими прикладами та акцентом на "чому це працює саме так".

🎓 CS50: Архітектура Nginx. Магія Event-Driven моделі

Привіт, світе! 👋 Радий бачити вас на цій лекції.

Сьогодні ми зазирнемо під капот одного з найпопулярніших веб-серверів у світі. Ви, напевно, бачили його назву тисячі разів у заголовках HTTP або в конфігах. Це Nginx (читається як "engine-ex").

Але чому він такий швидкий? Чому він може обробляти 10,000 підключень одночасно на звичайному ноутбуці, тоді як інші сервери задихаються? Секрет не в магії. Секрет в архітектурі.

Поїхали розбиратися! 🚀

1. 🔥 Вступ: Чому старі методи не працюють?

Уявіть, що ви відкрили піцерію. 🍕

На початку у вас є класична модель обслуговування (схожа на старий сервер Apache): На кожного клієнта ви наймаєте одного офіціанта. 1. Клієнт прийшов -> Офіціант прийняв замовлення. 2. Клієнт чекає піцу -> Офіціант стоїть біля столика і теж чекає. Він нічого не робить, просто дивиться, як клієнт чекає. 3. Клієнт їсть -> Офіціант чекає рахунку.

Якщо прийде 5 клієнтів — вам треба 5 офіціантів. Все супер. Але... що станеться, якщо прийде 10,000 клієнтів?

Вам доведеться найняти 10,000 офіціантів. Вони не помістяться в ресторані (оперативна пам'ять закінчиться). Вони будуть штовхатися (перемикання контексту процесора). І ресторан впаде. 💥

Риторичне питання: Чи справді нам потрібен окремий офіціант, щоб просто стояти і чекати, поки піч спече піцу? Звісно, ні!

Nginx вирішив цю проблему інакше. Він сказав: "Нам не потрібно 10,000 офіціантів. Нам потрібен один, але дуже швидкий, який ніколи не спить і не чекає".

Це і є Event-Driven (подієво-орієнтована) модель. Без цього сучасний інтернет з Netflix, TikTok та Instagram просто не витримав би навантаження.

2. 🧠 Теоретична база: Як це працює "під капотом"

Давайте розберемо механіку. Тут немає нічого складного, якщо зрозуміти принцип.

🏗 Головні компоненти Nginx:

Master Process (Бос) 👔 Він лише один. Він не обробляє запити клієнтів. Його робота — читати конфігурацію і керувати "роботягами". Він як адміністратор ресторану: відкриває заклад і наймає персонал.
Worker Processes (Роботяги) 👷 Саме вони роблять всю роботу. І ось тут цікавий момент: їх зазвичай стільки ж, скільки ядер у вашого процесора.
- Маєте 4 ядра? Nginx запустить 4 воркери.
- Не 100, не 1000. Лише 4.

⚡️ Як 4 воркери обробляють 10,000 запитів? (Event Loop)

У кожного воркера є нескінченний цикл — Event Loop.

Уявіть нашого "супер-офіціанта" в Nginx-піцерії: 1. Клієнт А робить замовлення. 2. Офіціант записує його і віддає на кухню. Він не чекає! 3. Він миттєво повертається до входу і приймає замовлення у Клієнта Б. 4. Тут кухня дзвонить у дзвіночок: "Піца для клієнта А готова!". Це — Подія (Event). 5. Офіціант бачить подію, хапає піцу і несе Клієнту А.

Ключове поняття: Non-blocking I/O (Неблокуюче введення/виведення). Воркер ніколи не блокується (не зависає), чекаючи на відповідь від диска, бази даних або мережі. Він просто "ставить галочку" і йде далі.

❗️ Що треба запам'ятати: * Apache створює новий процес/потік на кожен запит (Process-based). * Nginx використовує один потік для тисяч запитів, швидко перемикаючись між подіями (Event-driven).

3. 🧪 Приклади: Від простого до реального

Давайте подивимось на конфігурацію.

Приклад 1: Скільки рук у нашого сервера?

Відкриваємо nginx.conf. Що ви очікуєте там побачити на самому початку?

user www-data;
worker_processes auto;  # <--- Ключовий рядок!
pid /run/nginx.pid;

Питання до вас: Чому ми пишемо auto, а не ставимо, скажімо, 100? (Подумайте секунду...)

Відповідь: Тому що Nginx — це про ефективність CPU. Якщо у вас 4 ядра, а ви створите 100 воркерів, процесор буде витрачати час на те, щоб перемикати увагу між ними, а не на роботу. auto означає "створи по одному на кожне ядро". Ідеальний баланс.

Приклад 2: Обмеження з'єднань

В блоці events ми бачимо ще дещо:

events {
    worker_connections 1024;
}

Що це означає? Це скільки одночасних клієнтів (подій) може тримати в голові один офіціант (воркер).

Математика Nginx: Якщо у вас 4 воркери (ядра) і кожен може тримати 1024 з'єднання: Max Clients = 4 * 1024 = 4096 одночасних користувачів.

Хочете більше? Просто збільшіть worker_connections. Це дешево для пам'яті!

4. 🛠 Практична частина

Час забруднити руки! Ось 5 завдань для вас.

🔹 Завдання 1: Розвідка

Запустіть у терміналі команду:

ps aux | grep nginx

Знайдіть процес master і процеси worker. Скільки воркерів ви бачите? Чи співпадає це з кількістю ядер вашого процесора (nproc)?

🔹 Завдання 2: Експеримент з босом

Змініть у конфізі worker_processes на 1. Перезавантажте Nginx (sudo nginx -s reload). Подивіться знову через ps aux. Що змінилося? (Ви змусили весь ресторан працювати з одним офіціантом. Для Nginx це все ще ок!)

🔹 Завдання 3: "Гаряча" заміна

Nginx вміє оновлюватися без розриву з'єднань. Уявіть, що ви змінили конфіг. Запустіть sudo nginx -s reload. Під капотом: Master процес запустить нові воркери з новим конфігом, а старим воркерам скаже: "Доробіть поточні замовлення і йдіть додому". Клієнти навіть не помітять!

🔹 Завдання 4: Міні-кейс

У вас сервер з 2 ядрами. Вам потрібно обробляти мінімум 10,000 одночасних з'єднань. Які значення ви поставите для: * worker_processes? * worker_connections?

(Підказка: worker_processes 2 (або auto). А worker_connections має бути не менше 5000. Краще 10000 для запасу).

🔹 Завдання 5: Питання "А що, якщо..."

А що, якщо Nginx почне виконувати дуже важку математичну задачу (наприклад, шифрування величезного файлу) і це займе процесор на 5 секунд? Чи заблокує це інших клієнтів?

(Відповідь: Так! Оскільки це один потік, важкі CPU-операції блокують Event Loop. Тому Nginx ідеальний для віддачі файлів і проксіювання, але не для важких обчислень. Для обчислень ми передаємо запит на Python/PHP/Go бекенд).

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в налаштуванні веб-сервера?

❌ Новачок думає: "Мій сервер гальмує. Поставлю worker_processes 1000, щоб було більше потужності!" Результат: Сервер "лягає" через оверхед на керування процесами.

✅ Профі думає: "Nginx — це лише диспетчер. Він має перекидати дані, а не думати. Я залишу worker_processes auto, але перевірю ліміти відкритої кількості файлів у Linux (ulimit -n), тому що в Linux кожне з'єднання — це файл. Якщо Nginx не може відкрити файл, він не зможе прийняти з'єднання".

Порада з практики: Ніколи не змушуйте Nginx робити важку роботу (зміна розміру картинок на льоту, складна логіка). Використовуйте його як ідеального регулювальника руху.

6. 🧩 Підсумок

Отже, що ми сьогодні дізналися?

Проблема: Модель "один процес на клієнта" (Apache-style) з'їдає всю пам'ять при великому навантаженні.
Рішення: Event-Driven архітектура Nginx. Один воркер обслуговує тисячі клієнтів, не блокуючись.
Архітектура: Є Master (адмін) і Workers (роботяги).
Головний скіл: Ви тепер знаєте, чому Nginx такий швидкий, і можете осмислено налаштувати кількість воркерів та з'єднань.

Що далі? Тепер, коли ми вміємо швидко приймати тисячі запитів, постає питання: а куди їх дівати? На наступному уроці ми поговоримо про Load Balancing (Балансування навантаження) — як Nginx може бути "диригентом" для цілого оркестру серверів.

Це було CS50 (по-нашому). Практикуйтесь, і до зустрічі! 👋