api-load-tester

api-load-tester — скилл TerminalSkills для подготовки и запуска нагрузочных проверок API. Он подходит для задач, где нужно измерить производительность, провести stress test, найти предел пропускной способности или понять, в какой точке сервис начинает нарушать заданные пороги. В исходном SKILL.md перечислены три поддерживаемых инструмента: k6, wrk и autocannon. k6 предлагается для сложных сценариев с несколькими шагами, собственными метриками и порогами; wrk — для быстрого теста одного endpoint; autocannon — когда в окружении уже есть Node.js. Это не выбор «лучшего» инструмента навсегда: вариант зависит от структуры сценария и доступного runtime. Сценарий строится от фактического описания API. В качестве входа можно использовать OpenAPI или Swagger, файлы маршрутов Express и FastAPI, типы запросов и ответов в TypeScript, dataclass в Python, структуры Go либо описание endpoint от пользователя. Перед генерацией запросов скилл рекомендует прочитать реальные типы, чтобы payload не был набором условных foo и test123. Для полей задаются реалистичные значения и распределения, например разные идентификаторы и количества; примерно в пяти процентах запросов полезно смешивать edge cases — длинные строки и специальные символы. Такая подготовка нужна, чтобы проверять поведение API под похожей на рабочую нагрузкой, а не только скорость одного искусственного запроса. В инструкции выделены три формы нагрузки. Ramp-up постепенно увеличивает число виртуальных пользователей и помогает найти breaking point; soak удерживает нагрузку длительное время для поиска утечек памяти и исчерпания соединений; spike моделирует резкий всплеск с последующим возвратом к обычному уровню. Для каждого этапа скилл предлагает фиксировать latency percentiles p50, p95 и p99, долю ошибок и достигнутый RPS. В k6-порогах из примера отдельно проверяются http_req_duration, включая p95 и p99, и http_req_failed. В итоговом отчёте должны быть результаты по этапам, первый уровень, на котором нарушены thresholds, и осторожная гипотеза о bottleneck по характеру ошибок. Для многошагового потока пример использует последовательность signup → login → create-project, случайные данные пользователя, JWT в авторизованных запросах, отдельные метрики времени каждого шага и паузы, имитирующие поведение человека. Автор скилла отдельно подчёркивает, что auth-flow важен: узкое место может находиться в проверке токена или обращении к session storage. Пауза между запросами с реалистичным think time около одной–трёх секунд позволяет тестировать пользовательскую конкуренцию, а не только максимальный throughput соединения. У скилла есть жёсткие эксплуатационные ограничения. Production нельзя нагружать без явного подтверждения цели и окружения; тест начинают с малого уровня и повышают постепенно. В отчёте нужно указать серверные ресурсы, число pod и размер базы. Повторное использование соединений k6 следует учитывать как модель браузера, а rate limit — отличать от дефекта производительности. Карточка описывает подготовку сценария и интерпретацию измерений, но не разрешает запуск на чужой инфраструктуре, не обещает конкретный RPS и не заменяет согласование безопасного тестового стенда.