beanstalkd/roadmap/epics/07-validation.md

07. Приёмка И Производительность

Статус: не начат. Baseline зависит от 01; итоговая приёмка зависит от 02-06.

Цель

Доказать корректность и полезность многопроцессного режима воспроизводимыми тестами. Наличие нескольких PID или рост общей загрузки CPU сами по себе не являются приёмкой.

Функциональная Матрица

Область	Обязательные сценарии
Регрессии	make, make check по матрице 01; полный прежний набор при сохранении legacy; новый режим с 1 и несколькими owners
Создание tube	Одновременные use/watch через разные frontend, delete/recreate, единственный default, отсутствие создания на stats-tube
Routing	Все команды из 04; use и watch на разных owners; операции по ID независимо от текущей tube
Lifecycle	Ready/reserved/delayed/buried, kick/kick-job, приоритеты и FIFO, несколько резерваций на сессию
Watch	watch target перед ignore default; отказ multi-watch reserve; смена tube с живыми резервациями
Сессии	reserve-job другого owner, touch/delete старых резерваций, чужой reserved job, cleanup всех owners
Таймеры	Reserve timeout 0/positive, TTR, DEADLINE_SOON, delay, pause/unpause; гонки на границах времени
I/O	Partial requests/replies, pipelining, half-close, медленный client, large body, broken IPC, некорректные frame lengths
Ресурсы	IPC backpressure, OOM, ограниченные buffers, утечки памяти/FD после многократного reconnect
Отказы	Kill frontend/owner/supervisor, restart generations, stale messages, duplicate requests при наличии retry
WAL	Раздельные logs, partial/full restart, удалённые максимальные ID, compaction, rotation, disk full, crash windows
Эксплуатация	Drain, startup failure, невозможность двух writers, несовместимая карта, старые данные
Статистика	Нет двойного счёта сессий, один default, корректные process/binlog поля, недоступный owner

Свойства Для Проверки

• Один job не имеет двух действующих резерваций, но обработка внешним worker может повториться после TTR. Не объявлять корректные TTR redeliveries дубликатами сервера.
• Один ожидающий reserve завершается ровно одним исходом либо закрытием соединения; поздний IPC-ответ не меняет этот исход.
• Зафиксированный набор полностью завершённых операций согласуется с итоговым состоянием при quiescent проверке. Не требовать атомарности произвольного распределённого stats snapshot.
• После завершённого cleanup не остаются ссылки умершей сессии; сообщение старого поколения не создаёт их заново.
• Успешные операции не теряются сверх заявленных гарантий WAL/fsync. Неизвестный результат при обрыве соединения учитывается отдельно от подтверждённого успеха.
• Недопустимая топология отвергается без модификации исходных данных.

Нагрузочная Матрица

1. Сравнить исходную версию, новый режим с одним owner, новый режим с 2/4/доступным числом owners и независимые исходные экземпляры как ориентир стоимости IPC.
2. Выполнить равномерную нагрузку по многим tubes, одну горячую tube и перекошенное распределение. Отдельно измерить создание/удаление множества короткоживущих tubes.
3. Варировать число frontend и клиентов; показать, не стал ли frontend/supervisor/генератор нагрузки новым bottleneck.
4. Повторить сравнения для WAL off/on, одинаковых -f/-F, размера body, queue depth и смеси команд.
5. Измерять throughput завершённых lifecycle и отдельных команд, p50/p95/p99 latency, CPU каждого процесса, RSS/суммарную память, IPC traffic/backlog, disk throughput/fsync latency.
6. Использовать прогрев, несколько повторов, одинаковые параметры сборки и инфраструктуры. Публиковать разброс и сырые результаты, а не только лучший запуск.
7. Сопоставить с численными критериями, зафиксированными в 01 после baseline и до итоговых тестов. Если пороги не выполнены, представить профиль и причину; эпик не считать пройденным автоматически.

Средства

• Существующие команды: make, make check, make bench. Последняя является набором микробенчмарков, а не end-to-end испытанием.
• Добавить Unix integration harness для запуска ролей, kill/restart и инъекции отказов; переиспользовать ct/ и существующие подходы testserv.c, где это сохраняет ясность.
• Для ошибок памяти использовать доступные sanitizers или эквивалентные средства на поддерживаемой платформе. Они не заменяют проверки межпроцессной семантики.
• Не завязывать таймерные тесты только на короткие sleeps: использовать синхронизацию/наблюдаемые события и разумные временные допуски, чтобы избежать flaky результатов.

Итоговые Артефакты

• Автоматические тесты и воспроизводимые команды их запуска.
• Отчёт по compatibility matrix с явными ограничениями нового режима и политикой старых данных.
• Отчёт по производительности с baseline, конфигурациями, численными результатами и выводом о bottlenecks.
• Проверенные эксплуатационные инструкции и перечень оставшихся ограничений: одна tube последовательна, cross-shard watch reserve и live migration отсутствуют.

Реализация считается завершённой только после выполнения общей приёмки из 00-overview.md, а не после успешного happy path на двух процессах.