97e26a65d5
Документация для следующего разработчика (4 файла, ~1500 строк по
существу), реальный нагрузочный baseline на stage, и автоматический
smoke на каждый push.
Доки:
- docs/ARCHITECTURE.md — карта слоёв, модулей, Program.cs composition
root, полный поток signup→post с трассировщиком ASP.NET pipeline.
- docs/MULTI-TENANCY.md — ITenantEntity + reflection query-filter,
stamping в SaveChanges, SuperAdmin override (read-only + edit-mode
с reason), 8 подводных камней, чеклист «как добавить tenant-сущность».
- docs/RUNBOOK.md — health-чеки, backup/restore с примером, смена SDK,
disaster-recovery на новый сервер, 6 описанных инцидентов
(включая docker-compose project name), БД-troubleshooting.
- docs/DEVELOPER-GUIDE.md — локальный setup, гочи integration-тестов,
полные паттерны (controller с permission + tenant-сущность с
RowVersion + 5 шагов миграции), валидация, structured-логирование,
«НЕ делать» список.
k6 baseline:
- tests/load/ — 3 скрипта (signup-burst, retail-sales-parallel,
sales-report-heavy) + README с инструкциями.
- docs/performance-baseline.md — реальные цифры на stage:
* signup p95 446ms @ 50 RPM (IP-лимит 60/мин держит);
* retail-sale sequential — 17/sec, p95 71ms;
* retail-sale @ VU>1 — 53% failure из-за race в
GenerateNumberAsync (unique-violation 23505 не ловится в
SaveOrFkErrorAsync) — P0 для следующего рефакторинга;
* reports на 1500 чеков — p95 50-114ms до VU=5.
CI:
- .forgejo/workflows/stage-verify.yml — on workflow_run после Docker
API/Web, wait-for-ready → tests/stage-smoke.sh → Telegram пинг.
- tests/stage-smoke.sh — 7-секундный bash-смок (curl+jq+python3),
5 этапов: health, signup, token, multi-tenant изоляция (B → 404
на product A, B → пустой список), полный документ-цикл
(supplier+supply.post → stock=100 → sale.post → stock=99).
Локальный прогон против stage — все этапы зелёные.
Build чистый, локальный прогон smoke зелёный. Sprint 12 закрывает
автономно-безопасный цикл — дальше нужен вход от user'а.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| README.md | ||
| retail-sales-parallel.js | ||
| sales-report-heavy.js | ||
| signup-burst.js | ||
k6 нагрузочные тесты
Сценарии нагрузочного тестирования API food-market через k6.
Подготовка
# k6 standalone (Linux)
wget -O- https://github.com/grafana/k6/releases/download/v0.55.0/k6-v0.55.0-linux-amd64.tar.gz | tar xz
mv k6-*-linux-amd64/k6 ~/bin/
# проверить
k6 version
Сценарии
| Файл | Что меряет |
|---|---|
signup-burst.js |
100 signup'ов за минуту — bootstrap новых tenant'ов под нагрузкой |
retail-sales-parallel.js |
1000 проведённых чеков параллельно за 5 минут (один tenant) |
sales-report-heavy.js |
Чтение отчёта /api/reports/sales при 10 000 уже-существующих продажах |
Запуск против stage
BASE_URL=https://test.admin.food-market.kz \
k6 run signup-burst.js
BASE_URL=https://test.admin.food-market.kz \
k6 run retail-sales-parallel.js
BASE_URL=https://test.admin.food-market.kz \
k6 run sales-report-heavy.js
Результаты сводятся в docs/performance-baseline.md.
Что k6 печатает
checks_total....: 100.00% 1000/1000
http_req_duration: p(50)=82ms p(95)=312ms p(99)=580ms
http_req_failed.: 0.00% 0/1000
iteration_duration: avg=512ms
Это «человеческие» метрики. Тонкое — через --out json=summary.json
или --out csv=... (k6 не имеет своего хранилища, только stdout/file).