Производительность: вопросы для собеседования QA

Нагрузочное тестирование проверяет систему под ожидаемой рабочей нагрузкой: измеряем latency, throughput, error rate и стабильность. Цель — подтвердить, что система выдерживает реальный трафик.

Стрессовое тестирование доводит систему до предела и за его пределы, чтобы выявить точку отказа, поведение при деградации и способность к восстановлению. Также существуют: soak testing (длительная нагрузка для выявления утечек памяти), spike testing (резкий скачок нагрузки).

Из практики: при стресс-тесте отдельно оцениваю поведение после превышения предела — восстанавливается ли система автоматически или зависает. Graceful degradation важнее, чем просто высокий порог.

Нужно чётко определить цели: метрики (p95/p99 latency, throughput, error rate), профиль нагрузки (ramp-up, пиковая нагрузка, продолжительность) и пороги приемлемости по SLO.

Перед запуском: репрезентативные тестовые данные, изолированное окружение, мониторинг ресурсов (CPU, RAM, БД). Инструменты: k6, JMeter, Gatling, Locust (Python).

Из практики: ценность нагрузочного теста — не красивый отчёт, а конкретный ответ: при какой нагрузке система начинает деградировать и как именно (ошибки, тормоза, падение).

Для базовой оценки производительности смотрю: время отклика ключевых операций (p50, p95, p99), пропускная способность (RPS), процент ошибок под нагрузкой.

Smoke-проверка производительности: запускаю 1–5 виртуальных пользователей и проверяю, что p95 не превышает установленный порог (например, 500ms для API). Инструменты: k6, JMeter, Gatling, Lighthouse для фронтенда.

Из практики: даже простой smoke-тест производительности на каждом деплое помогает заметить деградацию до релиза. Рост p95 на 30% — уже сигнал для расследования.

Сравню новую и предыдущую версии: запросы к базе, внешние вызовы, настройки кэша и конфигурацию окружения.

Проверю медленные участки через трассировку и метрики по эндпоинту, чтобы локализовать узкое место.

Из практики: часто проблема не в коде, а в конфигурации или изменившемся профиле нагрузки.

Load — обычная ожидаемая нагрузка. Stress — выше нормальной, ищем точку отказа. Soak (endurance) — длительная под обычной нагрузкой, ищем утечки и накопительные эффекты. Spike — резкие скачки. Scalability — как ведёт при горизонтальном/вертикальном масштабировании.

Дополнительно — capacity и volume для проверки на больших объёмах данных.

Из практики: всегда нужны load и stress. Soak делают перед мажорным релизом. Spike — для систем с пиковой нагрузкой (распродажи, события).

Со стороны клиента: время отклика (p50, p95, p99), throughput (запросов в секунду), error rate. Со стороны сервера: CPU, RAM, диск, сеть, GC pauses, размер пула соединений, длина очередей.

Со стороны БД: long-running queries, lock waits, replication lag, размер connection pool. Со стороны кеша/брокера — hit rate, length of queues.

Из практики: фокус на перцентилях (p95, p99), не на среднем. Среднее скрывает долгий хвост, который ощущает 1-5% пользователей.

Классика: JMeter (GUI, много плагинов), Gatling (DSL на Scala/Kotlin, отчёты), Locust (Python, скрипты), k6 (JS, современный CLI и cloud-режим).

Также: artillery, wrk, ab (Apache Bench для простых случаев). Для распределённой нагрузки — JMeter в распределённом режиме, k6 cloud, Locust workers.

Из практики: для нового проекта чаще выбирают k6 (легко писать, удобно интегрировать в CI) или Gatling (хорошие отчёты, для серьёзных команд). JMeter жив, но многословен.

Профайлинг — это снятие данных о том, где приложение тратит CPU/память/время: какие функции вызываются, как долго работают, где GC, где блокировки.

Инструменты: pprof (Go), JVM Flight Recorder + JFR, async-profiler (Java), Chrome DevTools Performance (JS), py-spy (Python).

Из практики: профайлинг применяют когда тесты показывают деградацию, но непонятно где. Снимают перед и после изменений, сравнивают.

Перцентиль — это значение, ниже которого попадает указанный процент измерений. p95 — 95% запросов быстрее этого значения, 5% медленнее.

Важны хвостовые перцентили (p95, p99, p99.9) — они показывают «долгий хвост», который не виден в среднем. Один пользователь из ста — это часто десятки тысяч пользователей в продакшен-системе.

Из практики: SLO/SLA обычно ставят на p95 или p99: «99% запросов отвечают за <500мс». Среднее по этой же выборке может быть 100мс — и казаться отличным.

Bottleneck — узкое место, ограничивающее производительность системы. Часто это CPU одного сервиса, медленные запросы к БД, ограниченный пул соединений, медленная сеть.

Поиск: при нагрузочном тесте смотрят, что упирается в потолок раньше других. Если CPU 95% — это компонент. Если CPU 30%, а отклик растёт — внешний (БД, сеть).

Из практики: «спасает» правильная инструментация. Без APM/трассировки в распределённой системе bottleneck ищется как иголка в стоге сена.

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

Идеально иметь оба: нагрузочное даёт уверенность перед релизом, мониторинг — реальную картину после.

Из практики: некоторые проблемы видны только под продакшен-трафиком (определённые комбинации запросов, патологические пользователи). Поэтому мониторинг — не замена тестам, а дополнение.

Chaos engineering — это практика намеренного внесения сбоев в систему (упадёт сервис, потеряется пакет, замедлится диск) для проверки, что система выдержит реальные неполадки.

Принципы: эксперимент в проде или близко к проду, минимальный blast radius, явные гипотезы, наблюдение метрик. Инструменты: Chaos Monkey, Litmus, Gremlin.

Из практики: подходит для зрелых команд с хорошим мониторингом. На раннем этапе важнее наладить базовое тестирование и наблюдаемость.

Core Web Vitals: LCP (Largest Contentful Paint), INP (отзывчивость), CLS (стабильность раскладки). Также TBT (Total Blocking Time), TTFB (Time To First Byte).

Тестируют на медленных сетях (slow 3G), на слабых устройствах (mobile CPU 4x slowdown в DevTools), на холодном и тёплом кешах.

Из практики: главное — измерять real-user metrics в проде (RUM). Lab-метрики (Lighthouse) показывают потенциал, RUM — реальность.

Признак: RSS/heap растёт со временем при стабильной нагрузке, в какой-то момент OOM. Снимают heap snapshot (или dump) в нескольких точках и сравнивают — кто прирастает.

В Java — JFR, jmap, MAT. В Go — pprof. В Node.js — Chrome DevTools или heapdump. В Python — tracemalloc, objgraph.

Из практики: запускают soak-тест на час-два, ловят рост. Чаще всего виновники — кеши без TTL, listeners без unsubscribe, забытые connections.

Системы мониторинга, отслеживающие метрики производительности в проде: latency, throughput, ошибки, трассы запросов. Datadog, New Relic, Dynatrace, Elastic APM, Prometheus + Grafana.

APM обычно подключают агентом в приложение — он автоматически собирает данные.

Из практики: незаменимо для production-поддержки. Без APM приходится копаться в логах вручную.

Распределённая трассировка: каждый запрос получает trace_id, который передаётся через все сервисы. В UI видна цепочка: API → сервис A → БД → сервис B.

Стандарт — OpenTelemetry. Backends: Jaeger, Zipkin, Tempo. Часто интегрируется с APM.

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

SLI — Service Level Indicator: измеряемая метрика (доступность, latency). SLO — Service Level Objective: внутренняя цель (99.9% времени availability). SLA — Service Level Agreement: договор с клиентом + штрафы.

Error budget = 100% - SLO. Если SLO 99.9%, у вас 0.1% бюджета ошибок в месяц (~43 минуты).

Из практики: error budget — основа SRE. Если бюджет потрачен — фокус на стабильность, не на новые фичи.

Кеш — хранение результата вычисления для повторного использования. Стратегии: cache-aside (приложение управляет), read-through (кеш сам подгружает), write-through (запись в кеш и БД), write-behind (записать в кеш, БД асинхронно).

Также: TTL (время жизни), eviction policies (LRU, LFU, FIFO).

Из практики: 80% производительности часто решается правильным кешированием. Но кеш — источник багов «вижу старые данные».

CDN (Content Delivery Network) — распределённая сеть серверов, кеширующих статику близко к пользователю. Cloudflare, Fastly, CloudFront, Akamai.

Тестируют: время отклика из разных регионов (с помощью webpagetest, lighthouse), правильность cache headers, инвалидацию (purge), fallback при сбое CDN.

Из практики: для пользователей в дальних регионах CDN снижает latency с секунд до миллисекунд. Важно проверять, что критичные ассеты попадают в CDN.

Pool соединений с БД, переиспользуемый приложением. Открытие нового соединения дорого (TCP, TLS, auth), а pool позволяет переиспользовать.

Параметры: max_size, min_idle, timeout. PgBouncer — внешний pooler для Postgres.

Из практики: pool size = около (cores * 2 + effective_disk) для CPU-bound операций. Слишком большой pool — больше блокировок в БД, не быстрее.

CPU profiling показывает, где тратится время процессора: какие функции, как часто. Sampling (раз в N мс) vs instrumenting (на каждый вызов).

Memory profiling: что выделяет память, где утечки, какие объекты живут долго. Heap dumps, allocation tracking.

Из практики: для оптимизации производительности — CPU. Для борьбы с OOM и leaks — memory. Часто запускают оба, чтобы получить полную картину.

Lighthouse — инструмент аудита веб-страниц от Google. Показывает: Performance, Accessibility, Best Practices, SEO. В Performance — Core Web Vitals (LCP, INP, CLS).

Запускают в DevTools, CLI или CI (lighthouse-ci). Даёт оценку 0-100 и конкретные рекомендации.

Из практики: lab-метрики (Lighthouse) показывают потенциал на чистой машине. Real-user metrics (RUM) — реальный опыт. Нужны оба.

Кэширование — хранение результата прошлой операции, чтобы не вычислять/получать его снова. В HTTP кэш может быть на клиенте (браузер), промежуточном узле (CDN, прокси), серверной стороне (Redis, in-memory).

Управляется заголовками: Cache-Control, ETag, Last-Modified, Expires. Сервер диктует политику, клиент/CDN следуют.

Из практики: основные баги — кэшируется то, что не должно (приватные данные), или не кэшируется то, что могло бы (статика). Решается явной политикой Cache-Control.