← Назад к вопросам
Приведи пример требования производительности в цифрах
1.0 Junior🔥 151 комментариев
#Требования и их анализ
Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI29 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Пример требований производительности в цифрах
Контекст: система поиска объявлений на портале недвижимости
Разрабатываю требования для системы поиска недвижимости (как Avito, 2GIS). Дам конкретные примеры SLA требований с цифрами и обоснованием.
1. Требования на скорость отклика (Latency Requirements)
Requirement #1: Search API Response Time
Операция: GET /api/v1/properties/search?location=Moscow&price_max=5000000
Требование производительности:
- P50 (средний случай): ≤ 200 ms
- P95 (плохой случай): ≤ 500 ms
- P99 (очень плохой случай): ≤ 1000 ms
- Max (абсолютный максимум): ≤ 2000 ms
Обоснование:
- 200ms - психологический порог. Пользователь не ощущает задержку
- 500ms - лимит для хорошего UX. Пользователь начинает замечать, но это OK
- 1000ms - граница терпения. Если система медленнее, юзер раздражается
- 2000ms - абсолютный максимум. Если дольше, пользователь уйдёт на конкурентов
Эти цифры основаны на исследованиях:
- Nielsen research: 100ms — порог мгновенного отклика
- Google: 200ms задержка → 0.4% потерь пользователей
- Amazon: 100ms задержки → 1% потерь продаж
Requirement #2: Detail Page Load Time (Full Page)
Операция: GET /properties/{id} (полная страница с фото, описанием, картой)
Требование:
- P50: ≤ 300 ms
- P95: ≤ 800 ms
- P99: ≤ 1500 ms
Обоснование:
- Сложнее чем поиск (фото, карта, история, отзывы)
- Пользователь уже выбрал конкретное объявление, поэтому готов ждать чуть дольше
- Но не более 1.5 сек, иначе пойдёт смотреть другой объект
2. Требования на пропускную способность (Throughput Requirements)
Requirement #3: Concurrent Users Handling
Сценарий нагрузки: типичный рабочий день в Москве (18:00-21:00)
Требуемая пропускная способность:
- Пиковое количество одновременных пользователей: 50,000
- Количество запросов в секунду (RPS): 15,000 req/sec
- Среднее количество запросов на пользователя: 0.3 req/sec
Обоснование расчета:
- Месячные активные пользователи: 5 млн
- Средняя сессия: 10 минут
- Конверсия в активность днём: 5% (250k из 5млн онлайн днём)
- Пиковое время: 20% на 3 часа = 250k * 20% = 50k
- Запросы: search (0.15 req/s) + detail page (0.08 req/s) + other (0.07 req/s) = 0.3
Съёмка данных:
SELECT
COUNT(DISTINCT user_id) as concurrent_users,
COUNT(*) / 3600 as rps -- запросов в секунду
FROM request_logs
WHERE timestamp >= NOW() - INTERVAL '1 hour'
AND timestamp >= '2024-10-15 20:00:00'
AND timestamp <= '2024-10-15 21:00:00';
-- Результат: 48,342 users, 14,876 RPS (близко к требованию)
Requirement #4: Data Processing Throughput
Операция: Обновление индекса поиска (Elasticsearch) с новыми объявлениями
Требование:
- Минимум 5,000 документов в секунду (5k docs/sec)
- Лаг обновления индекса: ≤ 30 секунд
Обоснование:
- Ежедневный объём новых объявлений: 50,000
- Время обновления: 50,000 docs / 5,000 docs per sec = 10 секунд (с запасом)
- Лаг 30 сек означает, что новое объявление видно в поиске за полминуты
- Для недвижимости это приемлемо (пользователь не ожидает real-time как в соцсетях)
3. Требования на доступность (Availability Requirements)
Requirement #5: Service Availability SLA
Требование:
- Доступность сервиса: 99.9% (SLA for uptime)
- Максимально допустимое время простоя в месяц: 43.2 минуты
(30 дней * 24 часа * 60 минут * 0.001 = 43.2 минуты)
Разбор по компонентам:
Компонент | Требуемая доступность | Допустимое время простоя
-----------------------+-----------------------+------------------------
Search API | 99.95% ("four nines") | 21.6 минут/месяц
Database (PostgreSQL) | 99.99% ("five nines") | 2.16 минут/месяц
Cache (Redis) | 99.9% ("three nines") | 43.2 минут/месяц
Elasticsearch Cluster | 99.95% ("four nines") | 21.6 минут/месяц
File Storage (images) | 99.9% ("three nines") | 43.2 минут/месяц
Обоснование:
- Search API = критично, нужны 99.95%
- БД = уникальный источник данных, 99.99%
- Cache = можем жить без него, 99.9%
- Elasticsearch = можем восстановить из БД, 99.95%
Расчет SLA системы:
Общая доступность = 99.95% * 99.99% * 99.9% * 99.95% * 99.9%
≈ 99.68% (примерно)
Нужно проектировать так, чтобы итоговая доступность была не менее 99.9%
4. Требования на масштабируемость (Scalability Requirements)
Requirement #6: Horizontal Scalability
Требование: система должна масштабироваться линейно
Тестовые сценарии:
1. Однопоточное (baseline):
- 1 инстанс API
- RPS: 1,000
- Response time P95: 250ms
2. С линейным масштабированием:
- 2 инстанса API (+ load balancer)
- RPS: 2,000 (удвоилось)
- Response time P95: 250ms (не изменилось)
3. Полное масштабирование:
- 16 инстансов API
- RPS: 16,000 (увеличилось в 16 раз)
- Response time P95: 250ms (стабильно)
Ошибки масштабирования (требования НА масштабируемость):
Проблема: Sticky sessions в load balancer
- Если load balancer направляет всех пользователей одного сессии на один сервер
- То при 16 серверах одна сессия будет работать в 16 раз медленнее
- Требование: использовать stateless design, хранить сессии в Redis
Проблема: Пулинг коннектов в БД
- Каждый инстанс API открывает 20 коннектов к БД
- 16 инстансов * 20 = 320 коннектов
- PostgreSQL по умолчанию может обработать только 100 коннектов
- Требование: использовать PgBouncer для pooling (400 коннектов от клиентов → 40 к БД)
5. Требования на использование ресурсов (Resource Utilization)
Requirement #7: CPU & Memory Limits
При пиковой нагрузке 15,000 RPS:
А. Требование по CPU:
- Максимальное использование CPU: 70% при пиковой нагрузке
- Средное использование: 30%
- Запас для spikes: 30%
Расчет:
- Типичный инстанс (AWS c5.xlarge): 4 CPU cores
- 1000 RPS требует примерно 0.5 CPU (при нормальной оптимизации)
- 15,000 RPS требует 7.5 CPU
- С 70% утилизацией нужно 7.5 / 0.7 = 10.7 CPU
- Развернули 16 инстансов (16 CPU total) → 56% утилизация ✓
Б. Требование по Memory:
- Максимум на инстанс: 4 GB при пиковой нагрузке
- Минимум: 1 GB for baseline
- Требуемый размер инстанса: 8 GB (с запасом для JVM heap, buffers)
Почему 8 GB для инстанса на 4 GB базового использования?
- JVM heap: 2 GB
- OS и buffers: 1 GB
- Cache слой: 1.5 GB
- Запас для spikes: 1.5 GB
- Итого: 8 GB
В. Требование по Network:
- Bandwidth per instance: минимум 1 Gbps
- Total cluster bandwidth: 16 Gbps
Обоснование:
- Средний ответ API: 15 KB
- 15,000 RPS * 15 KB = 225 MB/sec = 1.8 Gbps
- На 16 инстансов: 1.8 / 16 = 112 Mbps на инстанс ✓ (достаточно)
Requirement #8: Storage Requirements
Требование на хранение данных:
А. Основная БД (PostgreSQL):
- Размер: 500 GB
- Рост: 50 GB в месяц
- Требуемое хранилище: 1 TB (с запасом на бэкапы)
Б. Search Index (Elasticsearch):
- Размер индекса: 100 GB
- Рост: 5 GB в месяц
- Репликация (3 реплики): 100 GB * 3 = 300 GB
В. Изображения (S3/Object Storage):
- Объём: 2 TB (4 млн объявлений * 500 KB среднее)
- Рост: 200 GB в месяц
- Требуемое хранилище: 3 TB
- Требуемый трафик: 500 Mbps при пиковой нагрузке
Г. Логи и аналитика:
- Размер в день: 100 GB
- Требуемое хранилище для 30 дней: 3 TB
6. Требования на задержку обновлений (Consistency Requirements)
Requirement #9: Eventual Consistency
Новое объявление на портале:
Операция 1: Пользователь создаёт объявление
- Write в основную БД: ≤ 100 ms
Операция 2: Объявление видно в профиле пользователя
- Consistency: Strong consistency
- Требование: ≤ 200 ms (почти synchronous)
Операция 3: Объявление видно в поиске
- Consistency: Eventual consistency
- Требование: ≤ 30 секунд
- Почему дольше? Нужно обновить Elasticsearch индекс
Операция 4: Объявление видно в рекомендациях
- Consistency: Eventual consistency
- Требование: ≤ 5 минут
- Почему ещё дольше? Нужно переобучить ML модель
Текущая реализация:
- 1: Write в primary DB ✓ 50ms
- 2: Read из primary DB ✓ 30ms (strong)
- 3: Async job отправляет в ES каждые 10 сек ✓ ~15 сек (eventual)
- 4: ML batch процесс каждый час ✓ ~30 минут (eventual, нужно улучшить)
Улучшение #4: Добавить real-time ML pipeline
- Требование: ≤ 5 минут
- Решение: отправлять новые объявления в отдельную очередь
- Переобучение ML модели каждые 5 минут вместо часа
7. Требование на мониторинг и алерты
Requirement #10: Alerting SLA
Когда система нарушает SLA, нужны алерты:
Метрика | Threshold | Action
----------------------+--------------+----------
API Latency P95 | > 500ms | Page oncall in 1 min
API Error Rate | > 0.1% | Page oncall in 2 min
Database CPU | > 80% | Alert, scale up in 5 min
Elasticsearch Lag | > 60 sec | Alert, investigate
Disk Usage | > 85% | Alert next morning
Memory Usage | > 90% | Page oncall immediately
Требование:
- Время обнаружения проблемы: ≤ 30 секунд
- Время уведомления инженера: ≤ 1 минута
- Время начала расследования: ≤ 2 минут
Пример полного документа требований
ПРОЕКТ: Система поиска недвижимости
ВЕРСИЯ: 2.0
ДАТА: 2024-10-15
## Performance SLA
| SLA Metric | P50 | P95 | P99 | Max |
|------------|-----|-----|-----|-----|
| Search Response | 200ms | 500ms | 1000ms | 2000ms |
| Detail Page | 300ms | 800ms | 1500ms | 3000ms |
| API Availability | - | - | - | 99.9% |
| Search Index Lag | - | - | - | 30s |
## Capacity Planning
| Resource | Baseline | Peak | Capacity |
|----------|----------|------|----------|
| Concurrent Users | 5,000 | 50,000 | 100,000 |
| RPS | 1,500 | 15,000 | 20,000 |
| CPU Cores | 4 | 10 | 16 |
| Memory | 8 GB | 24 GB | 32 GB |
| Database Size | 300 GB | 500 GB | 1 TB |
## Success Criteria
✓ 95% запросов отвечают за ≤ 500ms
✓ 99% запросов отвечают за ≤ 1s
✓ Система доступна 99.9% времени
✓ Новое объявление видно в поиске за 30 сек
✓ Система может обработать 2x пиковую нагрузку
Как использовать эти требования в реальности
-
Тестирование производительности (load testing)
# Используем Apache JMeter или Gatling - Генерируем 15,000 RPS нагрузку - Измеряем latency distribution - Проверяем соответствие требованиям P95 < 500ms -
Мониторинг в продакшене
- Prometheus метрики - Alert если P95 > 500ms - Dashboards для visibility -
Capacity planning
- Рост пользователей +20% в год - Инфраструктура масштабируется за ними - Проверяем capacity ежемесячно
Ключевое правило: все требования должны быть измеримы и проверяемы в цифрах!