Нагрузка и сбои: измерить, объяснить, повторить

Эксперимент начинается с вопроса

Вы уже можете создать задание и посмотреть метрики. Теперь проверьте границы: что происходит, когда запросы приходят быстрее обработки, когда файл повреждён и когда сервис останавливается с занятой очередью. Перед каждым опытом запишите ожидание. После него сравните наблюдение, а не только наличие строки PASS.

Локальный клиент и сервер делят один компьютер. Полученные числа характеризуют этот опыт, а не будущую производительность в облаке. Быстрый Analyze может не заполнить очередь даже при двухстах запросах; это тоже результат. Для воспроизводимой перегрузки используйте управляемую медленную Process в тесте и достаточное число обращений, а не утверждайте, что любой запуск команды обязан дать 429.

Что прочитать

Прочитайте требования и математику нагрузки, рост нагрузки, разделы о восстановлении в надёжности. Вернитесь к проверкам отмены и гонок в утечках и гонках Go.

Запустите ограниченную нагрузку

В первом терминале запустите сервер из папки проекта. Во втором запустите включённый клиент:

go run ./cmd/load -requests 200 -concurrency 8 -url http://127.0.0.1:8080

requests — общее число обращений клиента, concurrency — сколько он выполняет одновременно. Это не обещание фиксированного RPS. Пока сервер работает, снимите /metrics. Сохраните параметры WORKERS, QUEUE_SIZE, путь DATA_FILE, версию Go и вывод клиента. По умолчанию сервер использует два обработчика и очередь на шестнадцать ожидающих заданий.

Измеряйте отдельно длительность POST, количество ответов 202, 429 и прочих ошибок, а затем итоговые состояния принятых заданий. Быстрый 202 не доказывает быстрое выполнение. Если клиент не наблюдает завершение, дополнительно опросите принятые id или сравните состояние сервера после опустошения очереди. Для небольшого набора данных распределение задержек может быть нестабильно: сохраните исходные результаты и число измерений.

Проведите три проверки сбоя

1. Перегрузка. В своём тесте удержите Process, заполните очередь, проверьте отказ и максимальное число одновременно работающих обработчиков. Затем освободите их и дождитесь завершения. Сервис должен ограничивать приём, а не накапливать горутины на каждый отклонённый запрос.
2. Перезапуск. Используйте отдельный файл, создайте работу и прервите отдельно запущенный сервер до сохранения результата. Запустите снова и проверьте восстановление. Повтор расчёта допустим; исчезновение принятого задания надо исследовать. Отдельно испортите копию файла и проверьте ошибку запуска. Не называйте этот опыт тестом потери питания.
3. Остановка. Создайте медленную кооперативную Process. Начните Shutdown с коротким дедлайном, проверьте отказ новых запросов и сигнал отмены. После возвращения Process убедитесь, что тестовые горутины завершились. Отмена context сама по себе не служит доказательством завершения.

Пройдите проверки и напишите отчёт

go test ./... -run '^TestStage0[1-7]' -count=1
go test -race ./... -run '^TestStage0[1-7]' -count=1
go build ./...

Отчёт положите в свой проект. Достаточно таблицы: вопрос, условия, ожидаемое поведение, наблюдение, вывод. Для каждого сбоя укажите способ воспроизведения и ограничения опыта. Если исправили код, повторите именно провалившийся сценарий и ранние тесты, которые он мог затронуть.

Ошибки: считать скорость выдачи id скоростью обработки; сравнивать разные размеры текста без указания; использовать бесконечный генератор запросов; удалять файл, чтобы скрыть ошибку восстановления; объявлять отсутствие гонок по одному запуску обычного теста.

Когда идти дальше

Вы должны воспроизвести опыт другой командой после чистого запуска и объяснить хотя бы одно расхождение с ожиданием. Если всё совпало, измените число обработчиков или размер очереди и сформулируйте, какое наблюдение может измениться и почему. Затем подготовьте защиту архитектуры.