Модуль 34

Performance tuning та worker-параметри

Ось готовий урок, створений у стилі CS50: енергійний, з живими прикладами, без нудної теорії, але з глибоким розумінням "суті речей".

🎓 Урок: Performance Tuning та Worker-параметри

(Або: Як не "вбити" сервер, коли до вас прийшли 10 тисяч користувачів)

1. 🔥 Вступ: Чому ваш код працює швидко лише для вас?

Привіт, друзі! 👋

Уявіть ситуацію. Ви написали геніальний код. На вашому ноутбуці ("localhost") усе літає 🚀. Ви натискаєте кнопку, сторінка відкривається миттєво. Ви щасливі, замовник щасливий.

Ви викладаєте проєкт у світ (Deploy). Приходить перша сотня користувачів... і раптом сайт починає "думати" по 5 секунд. Приходить тисяча — і сервер падає з помилкою 502 Bad Gateway.

❓ Питання до вас: Чому так сталося? Адже код не змінився! Він той самий, що й на вашому ноутбуці.

Відповідь криється в "Ефекті Кав'ярні". Уявіть маленьку кав'ярню, де працює один бариста (це ваш серверний процес). * Коли ви один — ви отримуєте каву за хвилину. * Коли вас 10 у черзі — останній чекає 10 хвилин. * А якщо хтось замовив складний лате з мигдальним молоком і корицею (важкий SQL-запит), бариста зайнятий ним 3 хвилини, а всі інші просто дивляться у спину баристі й чекають.

Сьогодні ми навчимося "наймати" правильну кількість барист (воркерів), щоб черга рухалася швидко, але кухня не згоріла від тісняви.

2. 🧠 Теоретична база: Що там "під капотом"?

Перш ніж крутити налаштування, розберімося з двома фундаментальними поняттями. Без них тюнінг — це просто гадання на кавовій гущі.

🚗 Процеси vs Потоки (Processes vs Threads)

Уявіть, що ваш сервер (наприклад, Gunicorn для Python або Puma для Ruby) — це менеджер. Він може створювати Воркерів (Workers).

  1. Воркер як Процес (Process):

    • Це окремий бариста зі своєю власною кавомашиною і запасом молока.
    • Вони не заважають одне одному. Якщо один розлив молоко (впав з помилкою), інші працюють далі.
    • Мінус: Кожен бариста вимагає багато місця (оперативної пам'яті).

  2. Воркер із Потоками (Threads):

    • Це один бариста, але в нього 4 руки.
    • Він може одночасно натискати кнопку на кавомашині однією рукою і брати гроші іншою.
    • Плюс: Займає менше місця.
    • Мінус: Руки належать одній людині. Якщо мозок "зависне" над складним завданням, усі 4 руки зупиняться.

🏋️ CPU-bound vs I/O-bound (Золоте правило вибору)

Ось це треба запам'ятати назавжди:

  • CPU-bound (Задачі для процесора): Шифрування, обробка відео, складні математичні розрахунки, Machine Learning. Тут працює мозок.
    • Стратегія: Вам потрібно більше Процесів (окремих мізків).
  • I/O-bound (Задачі введення-виведення): Запит до бази даних, скачування файлу з інтернету, запис на диск. Тут процесор чекає, поки прийдуть дані.
    • Стратегія: Вам потрібно більше Потоків (Threads) або асинхронність. Поки одна "рука" чекає відповіді від БД, інша вже приймає замовлення.

3. 🧪 Приклади: Від одного до багатьох

Ми будемо використовувати приклад на Python (Gunicorn), але логіка ідентична для PHP (PHP-FPM), Node.js (Cluster) чи Ruby.

Сценарій 1: "Одинак" (Дефолт)

Ви запускаєте сервер командою: gunicorn app:app (За замовчуванням: 1 воркер).

Уявімо код, який імітує важку роботу:

# app.py
import time
from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return "Привіт! Я швидкий!"

@app.route('/heavy')
def heavy():
    # Імітуємо складну задачу (наприклад, генерацію PDF)
    # Цей процес БЛОКУЄТЬСЯ на 10 секунд
    time.sleep(10)
    return "Хух, я закінчив!"

🛑 Що станеться? Якщо користувач А зайде на /heavy, сервер "засне" на 10 секунд. У цей момент користувач Б заходить на головну сторінку / (яка має бути миттєвою). Результат: Користувач Б чекає 10 секунд, хоча його запит простий! Тому що бариста (воркер) зайнятий.

Сценарій 2: Масштабування (Додаємо воркерів)

Ми змінюємо команду запуску: gunicorn -w 4 app:app (4 воркери).

✅ Що змінилося? * Користувач А заходить на /heavy. Воркер №1 бере цю задачу і блокується. * Користувач Б заходить на /. Менеджер бачить, що Воркер №1 зайнятий, і віддає задачу Воркеру №2. * Результат: Користувач Б отримує відповідь миттєво!

Сценарій 3: "Псевдо-оптимізація" (Помилка новачка)

"Якщо 4 воркери — це добре, то поставлю 100 воркерів! Буде літати!" — думає початківець. Запускаємо: gunicorn -w 100 app:app.

☠️ Що станеться? * Кожен воркер — це копія вашої програми в пам'яті (RAM). Якщо програма їсть 100 Мб, то 100 воркерів з'їдять 10 Гб. * Сервер починає використовувати Swap (диск замість RAM), все стає неймовірно повільним. * Процесор витрачає більше часу на перемикання між 100 воркерами (Context Switching), ніж на корисну роботу. Це як якби бариста намагався робити 100 кав одночасно, роблячи по одному руху для кожної чашки по колу.

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

Час "забруднити руки". Якщо у вас є Python, спробуйте це прямо зараз. Якщо ні — змоделюйте в голові.

Завдання 1: "Ефект затору" 1. Створіть простий сервер (код вище). 2. Запустіть з 1 воркером. 3. Відкрийте дві вкладки браузера. У першій запустіть "важкий" запит, у другій одразу — "легкий". 4. Переконайтеся, що друга вкладка "висить". Це біль. Відчуйте цей біль.

Завдання 2: "Формула успіху" Для CPU-bound задач (більшість веб-сайтів) стандартна формула кількості воркерів: $$Workers = (2 \times CPU_Cores) + 1$$ Якщо у вас 2 ядра, ставте 5 воркерів.

  1. Дізнайтеся, скільки ядер у вашого процесора.
  2. Запустіть сервер з розрахованою кількістю воркерів.
  3. Повторіть тест із Завдання 1. Чи зникла черга?

Завдання 3: Міні-кейс "Чорна п'ятниця" Ваш сервер має 4 ядра і 8 Гб RAM. Ваша програма "важить" 500 Мб в пам'яті. Ви хочете поставити 20 воркерів, щоб обробити наплив покупців. * Питання: Чи це гарна ідея? * Підказка: Порахуйте загальну пам'ять: $20 \times 500 \text{ Мб} = ?$

Завдання 4: А що, якщо... А що, якщо ваша задача — це не складні обчислення, а очікування відповіді від зовнішнього API (наприклад, чат-бот чекає відповідь від OpenAI)? * Чи допоможе тут збільшення кількості процесів-воркерів? * Чи краще використати потоки (threads) або асинхронність (async)? Чому?

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

Як відрізнити сеньйора від джуніора в темі перформансу?

1. Не гадайте, а вимірюйте. Новачок каже: "Мені здається, треба більше воркерів". Досвідчений каже: "Я подивився на графіки htop або моніторингу. У нас CPU завантажений лише на 10%, але пам'ять забита. Додавати воркерів не можна, треба оптимізувати пам'ять або додати треди".

2. Пам'ять — це ресурс №1. Воркери "ненажерливі". У хмарі (AWS/Google Cloud) ви платите за RAM. Запуск 50 воркерів на дешевому інстансі призведе до "OOM Killer" (Out of Memory Killer) — це коли операційна система жорстоко вбиває ваші процеси, щоб врятувати себе.

3. Тайм-аути рятують життя. Що, якщо воркер "завис" назавжди? Досвідчений розробник завжди налаштовує --timeout. Якщо воркер не відповів за 30 секунд — менеджер його "пристрелить" і запустить нового, свіжого. Це називається "fail fast".

6. 🧩 Підсумок

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

  1. Один воркер — це вузьке місце. Будь-яка затримка блокує всіх.
  2. Більше воркерів ≠ завжди краще. Є ліміт процесора і пам'яті.
  3. Формула: (2 x Cores) + 1 — це ваша відправна точка.
  4. Тип задачі має значення. Для важкої математики — процеси. Для очікування мережі — потоки або асинхронність.

Тепер ви не просто пишете код, ви вмієте його скейлити (масштабувати). Ви знаєте, як налаштувати сервер так, щоб він витримав навантаження.

🔜 У наступній серії: Ми налаштували воркерів, але база даних все одно "гальмує"? Ми поговоримо про Індекси в базах даних — як знайти голку в стозі сіна за 0.001 секунди, замість того щоб перебирати кожну соломинку вручну.

Це був CS50. Побачимось! 🎬

← До списку уроків Наступний урок →