Производительность и масштабирование

Skrum — универсальная панель управления проектами с ИИ: командный чат, задачи и спринты, нативные видеовстречи и входящая активность кода в одном рабочем пространстве, где каждое действие ИИ ждёт подтверждения человека.

Skrum спроектирован так, чтобы оставаться отзывчивым при росте рабочего пространства и в неудачные дни инфраструктуры. На этой странице собраны конкретные цифры, модель кэширования и режимы отказа.

Пороги нагрузки

Опциональные сценарии k6 в каталоге load/ удерживают Skrum в этих целях против составленной среды с детерминированными подставными провайдерами:

• Реалтайм-рассылка — 500 одновременных сокет-клиентов в одном канале, задержка p95 от сообщения до рассылки ≤ 250 ms, доля ошибок < 0.1%.
• POST сообщения — p95 ≤ 200 ms при 50 rps, доля ошибок < 0.5%.
• Чтение доски (GET /api/tasks?projectId=…) — p95 ≤ 150 ms при 100 rps, доля ошибок < 0.5%.
• Поиск (GET /api/search) — p95 ≤ 300 ms при 50 rps, доля ошибок < 1%.
• Сводка главной (GET /api/home/summary) — p95 ≤ 200 ms при 100 rps, доля ошибок < 0.5%.

Сквозной кэш чтения

Небольшой сквозной кэш чтения на Redis покрывает три горячих пути: список каналов на рабочее пространство, проекции досок проектов и сводку панели/главной. Каждый ключ снабжается префиксом accountId рабочего пространства — рабочее пространство читает только свои собственные закэшированные данные. Инвалидация управляется событиями реалтайм-хребта (message.posted, channel.*, task.*), а короткий TTL служит подстраховкой. Кэш хранит только уже авторизованные, несекретные проекции.

Устойчивость к хаосу

Когда зависимость падает, Skrum отказывает безопасно, а не пишет частично и не утекает данными.

• Redis лежит. Реалтайм и кэш деградируют; REST продолжает отдавать источник истины из Mongo и Postgres. Лимитеры отказывают безопасно (запрещают, никогда не открывают проход).
• Mongo или Postgres недоступны. Маршруты возвращают локализованную ошибку класса 503 — без необработанных падений и без частичной записи.
• MinIO или LiveKit лежат. Загрузка файлов и совещания безопасно отказывают с локализованной ошибкой; остальное приложение продолжает работать. См. Резервное копирование и восстановление.

Когда зависимость возвращается, сервис возобновляется автоматически — ручного перезапуска не требуется.

Частые вопросы

• Запускать ли набор k6 в CI? Да, через опциональную задачу. Сценарии нагрузки никогда не блокируют обычный pull request.
• Можно ли повысить TTL кэша? TTL умышленно короткий. Инвалидация по событиям — основной путь корректности; TTL нужен только на случай простоя Redis.
• Может ли кэш утечь между рабочими пространствами? Нет — каждый ключ снабжается префиксом accountId, и отдельный тест доказывает изоляцию между арендаторами.

См. также: Документация Skrum