Аудит производительности Convex

Диагностика и устранение проблем производительности в приложениях Convex — по одному классу проблем за раз.

Когда использовать

• Страница или функция Convex работает медленно или обходится дорого.
• npx convex insights --details сообщает о высоких bytes read, documents read или OCC conflicts.
• Низкочастотные read-пути используют реактивность там, где достаточно point-in-time reads.
• Ошибки OCC-конфликтов или избыточные повторные попытки мутаций.
• Высокое количество подписок или медленное обновление UI.
• Функции приближаются к лимитам выполнения или транзакций.

Когда НЕ использовать

• Первоначальная настройка Convex, настройка аутентификации или извлечение компонентов.
• Чистые миграции схемы без цели производительности.
• Разовые микрооптимизации без пользовательски или деплой-видимой проблемы.

Первый шаг: сбор сигналов

1. Если Health insights из дашборда уже доступны — используйте их как первоклассный источник.
2. Если доступен CLI insights, запустите npx convex insights --details. При необходимости добавьте --prod, --preview-name или --deployment-name.
3. Если runtime-сигналы недоступны — проводите аудит по коду, соблюдая ограничения.

Маршрутизация по сигналам

Рабочий процесс

1. Определить область проблемы

Выберите один конкретный пользовательский флоу из реального проекта. Запишите: точки входа функций; клиентские вызовы useQuery, usePaginatedQuery, useMutation; таблицы чтения и записи; является ли путь high-read, high-write или обоими.

2. Трассировка полного набора чтений и записей

Для каждой функции на пути: трассируйте каждый ctx.db.get() и ctx.db.query(); каждый ctx.db.patch(), ctx.db.replace(), ctx.db.insert(); внешние key-поиски, JS-side фильтрацию и полные чтения документов. В Convex каждое лишнее чтение увеличивает нагрузку на транзакцию, а каждая запись может инвалидировать реактивных подписчиков.

3. Применить исправления из подходящего справочника

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

4. Исправить смежные функции вместе

Если в одной функции, затрагивающей таблицу, обнаружена проблема производительности — проверьте смежные функции на тот же паттерн. Не оставляйте один путь исправленным, а другой — на старом паттерне.

5. Проверить перед завершением

• Результаты те же, что до исправления, нет потерянных записей.
• Устранённые чтения/записи больше не находятся на пути.
• Fallback-поведение работает при отсутствии денормализованных полей.
• Часто обновляемые поля изолированы от широко читаемых документов.
• Каждый смежный читатель и писатель проверен.

Чек-лист

• Собраны сигналы из insights, дашборда или аудита кода.
• Определён класс проблемы, прочитан соответствующий справочный файл.
• Очерчен один конкретный пользовательский флоу.
• Трассированы все чтения и записи на этом пути.
• Определены смежные функции, затрагивающие те же таблицы.
• Применены исправления из справочника.
• Смежные функции исправлены единообразно.
• Поведение проверено, регрессии отсутствуют.