# Задержка доставки: исправление 0.8.1

В0.8.0 MUC после каждого groupchat append запускал expire_before. Эта операция
под общим mutex компонента проходила по всему архиву и записывала сохранённые
записи во временный файл даже при отсутствии истёкших записей. Задержка каждого
сообщения росла с размером истории. Дополнительно переписывались неизменённые
native room config/persistent index, а CSI сохранял полную durable SM-сессию
даже при пустой/неизменённой очереди.

В0.8.1 эти лишние операции исключены из обычного пути доставки. Очистка архива
остаётся в периодическом maintenance (интервал сервера300с) и перед MAM-запросами.
Неизменённые native-файлы не переписываются; недостающие/изменённые экспорты и
повтор после ошибки сохранены. Авторитетный MUC checkpoint и SM state по-прежнему
записываются до подтверждения соответствующих изменений. CSI откатывает изменение
очереди при ошибке checkpoint. Ненаправленный в MUC account traffic обходит mutex
компонента и не ждёт его обслуживания архивов.

## Измерение

Настоящий STARTTLS, два клиента, durable SM, MUC MAM с finite retention,
active/inactive CSI. Изолированный loopback; архив native `.list` заполнен до
запуска сервера. Проверяются доставка sender echo/peer, counters, durable CSI
buffer/flush и точное число записей архива. Порог задержки в миллисекундах не
используется как flaky assertion; структурные регрессии запрещают полный scan
архива при append и запись неизменённых native-файлов.

Active CSI, MUC peer, мс:

| Записей истории | 0.8.0 median / p95 | 0.8.1 median / p95 |
|---:|---:|---:|
|0|9.425 / 11.221|5.054 / 7.643|
|1000|32.718 / 36.995|4.280 / 6.605|
|10000|259.472 / 269.067|4.895 / 6.307|
|100000|2517.940 / 2520.941|4.680 / 14.532|

Inactive CSI,100000 записей: median3866.027→4.285мс,
p95 4150.867→5.072мс. Первые три строки —5samples/state, последняя —3.
Это ограниченное сравнение на одном loopback host, а не production SLA и не
доказательство всех возможных причин задержки у реальных клиентов.
Полные сырые samples и SHA-256 обеих сборок — validation-logs-0.8.1/latency-*.json.

Команды:

```bash
python3 tests/message_latency_network.py --binary target/release/rust-xmpp \
  --rounds 5 --history-records 0 1000 10000 --output /tmp/message-latency.json
python3 tests/message_latency_network.py --binary target/release/rust-xmpp \
  --rounds 3 --history-records 100000 --output /tmp/message-latency-100k.json
```

Быстрая проверка0/10000 records уже включена в verify-local.sh и GitHub Actions.
Для повторной медленной проверки используйте сохранённую0.8.0 release-сборку;
не приписывайте исходному бинарнику результаты пересобранной новой версии.

## Если задержка остаётся в целевой установке

Сопоставьте время отправки, получения и отображения delivery/read receipt,
тип чата, transport, состояние CSI и наличие федерации. Доставка сообщения и
receipt — разные события. Native CSI policy для низкоприоритетных payload не
менялась. Длительный MAM query, периодическая очистка большого архива, медленный
диск или внешний XMPP-домен могут иметь отдельную задержку. Текущие изменения
не отключают fsync, не обещают exactly-once и не подменяют проверку реальных
Conversations/Monal/Gajim либо deployment.