Налаштування пріоритезації завдань у черзі (Priority Queue)

Уявіть: 90% користувачів покидають сайт, якщо лист скидання пароля не приходить протягом 5 секунд. А ваша черга забита 30-хвилинними звітами. Результат — втрата клієнтів і негатив. Ми стикалися з цим у проєкті з 150 000 активних користувачів: critical-завдання (скидання пароля, SMS-коди) стояли в одній черзі з експортами. Після впровадження пріоритезації latency для critical впало з 30 секунд до 2 секунд — у 15 разів швидше. Нижче — як ми це робимо.

За 5+ років роботи з чергами ми опрацювали понад 50 проєктів, від стартапів до enterprise. Наш підхід — спроектувати модель пріоритетів, налаштувати воркери та захистити систему від голодування. Без зайвих абстракцій, лише перевірені патерни.

Чому пріоритезація завдань у черзі критична для продуктивності?

Без пріоритезації всі завдання обробляються в порядку надходження (FIFO). Це призводить до неприпустимих затримок для критичних операцій. Наприклад, у high-traffic проєкті кожні 100 мс затримки знижують конверсію на 7%. Наші клієнти після налаштування пріоритетів бачать скорочення часу відповіді critical-завдань на 80–95%.

Модель пріоритетів

Типовий поділ на три рівні:

Вибір рівнів залежить від SLA вашого бізнесу. Для інтернет-магазину можна додати чергу high для замовлень.

Як налаштувати пріоритети в Laravel?

Laravel підтримує soft-пріоритет: воркер перебирає черги у вказаному порядку. Команда:

php artisan queue:work --queue=critical,default,low

Якщо в critical є завдання, воркер не переходить до default. Пріоритет задається при диспатчі:

SendPasswordResetEmail::dispatch($user)->onQueue('critical');

Або всередині Job через властивість $queue. Це простий і швидкий спосіб, але при довгих завданнях у low-черзі critical може чекати. Рішення — виділені воркери Horizon.

Порівняння soft-пріоритету та виділених воркерів

Як використовувати виділені воркери для критичних завдань?

Horizon дозволяє створити окремі пули воркерів для кожної черги. Порівняйте: soft-пріоритет — latency для critical може досягати хвилин при завантаженні low-черги. Виділені воркери гарантують < 5 секунд — у 10 разів швидше. Приклад конфігурації:

// config/horizon.php
'environments' => [
    'production' => [
        'critical-supervisor' => [
            'connection' => 'redis',
            'queue' => ['critical'],
            'balance' => 'simple',
            'minProcesses' => 2,
            'maxProcesses' => 8,
            'timeout' => 30,
        ],
        'default-supervisor' => [
            'connection' => 'redis',
            'queue' => ['default'],
            'balance' => 'auto',
            'minProcesses' => 1,
            'maxProcesses' => 5,
            'timeout' => 60,
        ],
        'low-supervisor' => [
            'connection' => 'redis',
            'queue' => ['low'],
            'balance' => 'simple',
            'processes' => 2,
            'timeout' => 3600,
        ],
    ],
],

Кожен supervisor працює незалежно: critical не блокується low-завданнями. Це стандартний патерн для high-traffic проєктів.

Що таке starvation і як його запобігти?

Starvation (голодування) — ситуація, коли низькопріоритетні завдання ніколи не обробляються через постійний приплив критичних. Це призводить до нескінченного накопичення звітів та експортів. Два основні рішення:

Aging — підвищення пріоритету з часом. Реалізуємо через scheduled job:

// підвищуємо пріоритет завдань, що очікують більше 30 хвилин
Schedule::call(function () {
    Job::where('queue', 'low')
        ->where('created_at', '<', now()->subMinutes(30))
        ->update(['queue' => 'default']);
})->everyFifteenMinutes();

Виділений воркер для low — один процес гарантує, що low-завдання рано чи пізно виконаються. Комбінація двох методів дає 100% захист.

Динамічний пріоритет на основі даних

Пріоритет можна призначати не статично, а залежно від користувача. Наприклад, enterprise-клієнтам — critical, звичайним — default. Це гнучкіше жорсткої схеми і економить ресурси.

Пріоритет у BullMQ (Node.js)

BullMQ використовує числові пріоритети через Redis Sorted Set. Це точніше Laravel, але вимагає окремої інфраструктури.

await queue.add('send-password-reset', { userId: 123 }, { priority: 1 });
await queue.add('generate-report', { reportId: 789 }, { priority: 10 });

Чим менше число, тим вищий пріоритет. У Laravel простіше, якщо стек вже на PHP.

Моніторинг та алертинг

Глибину черг відстежуємо через Redis: Redis::llen('queues:critical'). Horizon показує це в дашборді. Налаштовуємо алерти на зростання черг — сигнал нестачі воркерів. Рекомендуємо пороги: якщо critical > 50, default > 200 або low > 1000 — термінове оповіщення. Це запобігає простоям.

Що входить у роботу

1. Аудит поточної архітектури черг
2. Проектування моделі пріоритетів з SLA
3. Конфігурація воркерів (Horizon або BullMQ)
4. Захист від голодування (aging + виділений воркер)
5. Моніторинг та документація

Терміни: базове налаштування трьох черг — 3–5 годин. Логіка антиголодування та моніторинг — ще 2–4 години. Вартість розраховується індивідуально.

Оцінимо ваш проєкт — зв'яжіться з нами. Замовте налаштування черг — отримайте консультацію щодо вашого стеку.

Докладніше про Laravel Horizon (офіційна документація)

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.