wt
e9329ccbb2
сообщения больше не выполняется полный scan/rewrite архива для expiry. Очистка остаётся в maintenance и перед MAM-запросами; append и crash checkpoint до fanout сохранены. - Неизменённые native config/persistent index не перезаписываются при каждом сообщении. Удалённые файлы восстанавливаются, ошибки экспорта повторяются. - CSI больше не сохраняет SM snapshot при отсутствии изменения durable очереди. Изменённая очередь сохраняется до отправки; при ошибке записи очередь откатывается. - Личные сообщения, IQ и входящая федерация к аккаунтам больше не захватывают общий MUC mutex, ожидая несвязанную работу с комнатными архивами. - Добавлены регрессии native exports/archive scanning/CSI rollback и реальный TLS latency check в verify-local.sh, автоматически включённый и в CI. Измерения и границы подтверждения: [docs/MESSAGE-LATENCY.md](docs/MESSAGE-LATENCY.md). Результаты итогового прогона: [docs/VALIDATION-0.8.1.md](docs/VALIDATION-0.8.1.md). - Личные сообщения и SM ACK больше не ждут сетевую отправку push. Уведомления отправляются через очередь1024 с максимум8параллельных маршрутов; worker и его задачи отменяются при завершении serve. Ошибки очереди/маршрута логируются. - Offline сообщение сохраняется до публикации push, чтобы проснувшийся клиент мог сразу получить его. Подтверждена очередь при первом TLS stream push gateway. - По умолчанию CSI считает важными bodyless OMEMO legacy/2, delivery receipts и chat markers. Явный список `csi_important_payloads` заменяет расширенные defaults. Низкоприоритетный headline по-прежнему буферизуется. Policy обновляется и при SM resume. - Выбор адресатов и carbons фильтрует владельцев до захвата session mutex; зависшая сессия чужого аккаунта не задерживает этот путь. Duplicate SM ACK без изменения durable counters/queue не переписывает snapshot. - Bind2 и MAM metadata IQ читают только первый/последний native record вместо сканирования всей истории. Индекс не требуется; recovery/лимиты записи сохранены. - Добавлен `message-processing-slow`: обработка message дольше250мс, поля duration_ms/route, без payload/токенов. Это время обработки сервером, не peer receipt. - Новые сетевые регрессии включены в verify-local.sh/GitHub CI. Причины, изменение CSI policy, измерения и ограничения: [docs/PERSONAL-MESSAGE-LATENCY.md](docs/PERSONAL-MESSAGE-LATENCY.md).
4.7 KiB
Задержка доставки: исправление 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.
Команды:
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.