2.8 KiB
2.8 KiB
Производительность
Performance Budgets
| Метрика | Лимит (p95) | Примечание |
|---|---|---|
| API response (без AI) | < 500ms | |
| API response (с AI) | < 5s | Fallback после 5s |
| DB query (одиночный) | < 100ms | С индексом |
| DB query (агрегатный) | < 300ms | |
| WebUI page load | < 2s | |
| AI call | < 5s | Иначе fallback |
Индексы БД
Что индексировать:
- Поля в WHERE и JOIN:
user_id,status,email - Поля сортировки:
created_at - Внешние ключи:
user_id,parent_id
Формат имени индекса: ix_tablename_column
CREATE INDEX ix_ideas_user_id ON ideas(user_id);
CREATE INDEX ix_ideas_status ON ideas(status);
Connection Pool
engine = create_async_engine(
settings.database_url,
pool_size=10, # Постоянные соединения
max_overflow=20, # Дополнительные при пике
pool_pre_ping=True, # Проверка перед использованием
)
Для SQLite pool настраивать не нужно — он файловый.
Метрики (если реализованы)
Собираемые метрики:
| Метрика | Тип | Описание |
|---|---|---|
http_requests_total |
Counter | Всего запросов |
http_request_duration_ms |
Histogram | Время ответа (p50/p95/p99) |
http_requests_by_endpoint |
Counter | По endpoint'ам |
http_errors_total |
Counter | 4xx и 5xx |
db_query_duration_ms |
Histogram | Время запросов к БД |
ai_provider_calls |
Counter | Вызовы AI провайдеров |
agent_execution_duration |
Histogram | Время выполнения агентов |
Где хранить: в БД (таблица agent_metrics), в перспективе — Prometheus.
Когда оптимизировать
- Профилировать до оптимизации. Не гадать — измерять.
- Оптимизировать только горячие пути. 90% времени уходит на 10% кода.
- Кэшировать только то, что реально часто читается. Преждевременное кэширование — корень всех зол.
[ASK] Вопросы по производительности
- Нужен ли Redis кэш? (да, если часто читаются одни и те же данные)
- Нужен ли CDN для статики? (да, для production)
- Нужен ли database sharding? (нет, до 10M записей)