Два месяца спустя. Что я понял, пока пытался сделать E2EE-мессенджер / Comments / Habr

Прогнал локальный stress smoke, чтобы не отвечать «на глаз».

Сценарий был довольно жёсткий: большое количество отправок в реальном браузере, не напрямую через API. То есть путь был настоящий:

UI → frontend state/update → штатный send path приложения → backend → API response

Короткий автоматический прогон

На коротком автоматическом прогоне в 130 сообщений картина хорошая:

То есть на обычном сценарии сообщение появляется у отправителя практически мгновенно: p95 до optimistic render — меньше 100 ms.

Ручной stress-тест

Потом отдельно погонял ручной stress-тест: 2009 отправок в реальном браузере.

На этом уровне backend не развалился: все пойманные отправки получили HTTP 200.

Общие метрики ручного stress-теста

Деградация по мере роста количества сообщений

На длинной активной сессии деградация уже видна:

Самое интересное: сильнее всего растёт не только backend response time, а задержка до самого API request. Это указывает, что основной bottleneck появляется на клиенте: длинный список сообщений, React render/DOM, обработчики состояния, возможно IndexedDB/local state и отсутствие полноценной virtualization для длинной истории.

Короткий вывод

Интерфейс на обычном сценарии отзывчивый: десятки миллисекунд до optimistic render.

Backend на stress smoke тоже не развалился: 2009 отправок, 2009 успешных HTTP 200, без network failures.

Но при агрессивном long-chat stress на тысячах сообщений уже видно, где следующий инженерный шаг:

• virtualization списка сообщений;
• изоляция input-компонента от rerender списка;
• batching локальных updates;
• оптимизация обработки статусов/echo/realtime-событий;
• отдельный профайлинг decrypt/render длинной истории.

Важно: это локальный smoke/stress, а не production SLA. Ручной recorder в этом прогоне надёжно мерил send path до API 200; DOM render для длинной ручной сессии я буду мерить отдельным тестом открытия/скролла истории на 1000/5000/10000 сообщений.