Войти
Работаем: пн–пт 9:00–18:00Начать диагностику
Сервис может быть быстрым на тестовом стенде и рассыпаться под реальным профилем нагрузки. Средняя latency может выглядеть хорошо, пока p99 делает интерфейс непредсказуемым. CPU может быть свободен, а система стоять в очереди на базу данных. AMPE использует Performance & Scalability Engineering там, где throughput, latency, capacity и поведение под нагрузкой должны быть частью архитектуры, а не реакцией на уже случившийся bottleneck.
Начать диагностикуМедленным может быть: network round trip; SQL-запрос; lock; внешний API; serialization; очередь; GC; дисковый I/O; рендеринг на клиенте.
Если измерять только общее время запроса, источник задержки остаётся внутри чёрного ящика.
AMPE раскладывает путь запроса до конкретного ограничивающего ресурса.
Средняя latency 200 мс может сосуществовать с несколькими процентами запросов по 5–8 секунд.
Именно они формируют ощущение нестабильности.
Поэтому важны распределения и percentiles: p50; p95; p99; tail latency.
Особенно для систем, где длинный хвост влияет на цепочку зависимых вызовов.
Иногда узкое место — неправильный запрос.
Иногда — serial section, которую невозможно распараллелить.
Иногда — внешний лимит.
Иногда — один общий lock.
Горизонтальное масштабирование помогает только тем частям системы, которые способны действительно использовать дополнительные экземпляры.
AMPE сначала ищет ограничение, а уже потом увеличивает ресурс.
Когда latency нестабильна при пиковых нагрузках.
Когда система достигает потолка по throughput.
Когда рост пользователей требует непропорционально больше инфраструктуры.
Когда база данных становится общей точкой ограничения.
Когда внешние сервисы не выдерживают скорость входящего потока.
Когда batch-задачи мешают online-нагрузке.
Когда система должна выдерживать известный профиль будущего роста.
Cache может радикально снизить нагрузку.
Но появляются: TTL; invalidation; cache stampede; consistency; memory pressure; cold start.
Поэтому AMPE использует кэширование там, где стоимость повторного вычисления или чтения действительно оправдывает новый слой состояния.
Если входящий поток стабильно выше скорости обработки, очередь лишь откладывает перегрузку.
Нужны: capacity; backpressure; rate limiting; приоритеты; границы backlog.
AMPE рассматривает очередь как инструмент управления потоком, а не место, куда можно спрятать нагрузку.
Плавный рост и мгновенный spike создают разные эффекты.
Чтение и запись нагружают систему по-разному.
Равномерный трафик и hot keys — тоже.
Мы моделируем реальный профиль: соотношение операций; размер данных; concurrency; burst; длительность; внешние зависимости.
Нефункциональное требование получает измеримую форму.
SLO по latency связывается с профилем нагрузки. Capacity — с бизнес-ростом. Метрики — с конкретными ресурсами. Load test — с архитектурным ограничением. Результат — с решением по оптимизации или масштабированию.
Так производительность становится инженерно управляемой.
Узкие места становятся измеримыми.
Масштабирование можно планировать до деградации.
Инфраструктура увеличивается там, где это действительно помогает.
Backpressure и rate limiting защищают систему при перегрузке.
SLO перестают быть абстрактными требованиями.
И главное — производительность становится свойством архитектуры, а не бесконечной серией срочных оптимизаций.
Первый шаг
Для начала достаточно описать, при каком объёме, типе нагрузки или сценарии система начинает вести себя непредсказуемо. Диагностика покажет, где находится реальное ограничение и какой способ масштабирования оправдан.