Высокие нагрузки
Назначение
Сервис описывает поддержку стабильной работы системы при росте числа пользователей и операций. Включает обработку нагрузки через воркеры, очереди и настройки БД , оптимизацию больших списков и канбана , а также общие рекомендации по масштабированию.
Цели и задачи
- Обрабатывать рост одновременных запросов за счет пула воркеров и очередей.
- Оптимизировать запросы к БД и избегать N+1 и тяжелых отчетов в основном процессе.
- Выносить длительные операции в фоновые задания (bench worker).
- Оптимизировать представления с большим количеством карточек (канбан, списки) через Dinext и пагинацию.
- Мониторить производительность и настраивать лимиты и кэширование.
Для кого
- Администраторы и DevOps при настройке воркеров и БД.
- Разработчики при написании отчетов и фоновых задач.
- Руководители ИТ при планировании масштабирования.
Основные понятия
- Воркер (worker) — процесс обработки HTTP-запросов (gunicorn/uWSGI воркеры) и очередей заданий (bench worker). Увеличение числа воркеров повышает пропускную способность в пределах ресурсов сервера.
- Очередь заданий — разгрузка тяжелых операций в фоновые воркеры; основной веб-процесс не блокируется.
- Оптимизация БД — индексы, ограничение выборок (limit), избегание N+1 запросов; настройки пула соединений в database.py.
- Dinext — приложение для оптимизации отображения канбана при большом числе карточек (README).
- Нагрузочное тестирование — проверка поведения под пиковой нагрузкой до продакшена.
Основные сущности / объекты
- background_jobs.py, database.py .
- Dinext (README).
- Конфигурация: количество воркеров веб-сервера и bench worker, лимиты БД, Redis (очереди).
Основные сценарии / процессов
Масштабирование воркеров и очередей
- Увеличить число воркеров веб-сервера (gunicorn workers) в конфигурации в пределах числа ядер и RAM.
- Запустить достаточное количество процессов bench worker для очередей short, default, long; при росте очередей добавить воркеры или оптимизировать время выполнения заданий.
- Использовать отдельный Redis для очередей при высокой нагрузке; настроить персистентность и лимиты по документации.
- Тяжелые отчеты и массовые операции выполнять через enqueue, а не в HTTP-запросе.
Оптимизация запросов и представлений
- В отчетах и списках ограничивать выборку (limit_page_length, фильтры); избегать загрузки всех записей сразу.
- В коде избегать N+1: использовать get_all с полями и ссылками или join вместо цикла с запросами по одному документу.
- Для канбана с тысячами карточек использовать Dinext при установке; отображать карточки порциями или виртуализировать список.
- Добавлять индексы по полям, используемым в фильтрах и сортировках часто используемых списков (через миграции приложения).
Мониторинг и настройка БД
- Мониторить время отклика страниц и запросов к БД; выявлять медленные запросы через логи или мониторинг СУБД.
- Настроить пул соединений и таймауты в database.py (или в конфигурации) в соответствии с нагрузкой.
- Периодически анализировать и оптимизировать тяжелые отчеты и скрипты; кэшировать редко меняющиеся данные при возможности.
- При росте данных планировать партиционирование или архивирование старых записей по регламенту.
Правила и ограничения
- Рост воркеров увеличивает потребление RAM; балансировать с доступными ресурсами сервера.
- БД остается узким местом при большом числе одновременных запросов; рассмотрите read replicas и оптимизацию запросов перед бесконечным увеличением воркеров.
- Dinext решает проблему отрисовки большого числа карточек на клиенте; серверная выборка по-прежнему должна быть ограничена (пагинация, lazy load).
Результаты / отчетность
- Стабильное время отклика при пиковой нагрузке.
- Отсутствие накопления очереди заданий при нормальной нагрузке.
- Метрики мониторинга (RPS, время ответа, использование CPU/RAM, очередь заданий) для принятия решений по масштабированию.
Типовые вопросы и ошибки (FAQ)
Страницы открываются медленно при многих пользователях
Проверьте: количество воркеров веб-сервера; время выполнения запросов к БД (медленные запросы в логах); не выполняются ли тяжелые операции в основном запросе — перенесите их в фоновые задания. Проверьте нагрузку на БД и при необходимости добавьте индексы или оптимизируйте запросы.
Канбан «подвисает» при большом числе карточек
Установите и используйте Dinext для этого представления; приложение оптимизирует отрисовку. Дополнительно ограничьте выборку на сервере (фильтр по проекту/статусу, пагинация по страницам канбана).
Как понять, сколько воркеров нужно?
Эмпирически: начать с 2–4 воркеров веб-сервера и 1–2 bench worker на очередь; мониторить использование CPU и время ожидания в очереди. При росте очереди заданий — добавить воркеров очередей; при росте времени ответа страниц — добавить веб-воркеров или оптимизировать код. Нагрузочное тестирование поможет оценить лимиты.