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

[d3d11]

Много нейрогенерации. Попробуйте больше своих слов.

[grokfrog]

Возможно, местами получилось слишком гладко. Учту, спасибо.

[SysManOne]

Ну что вы прямо ... Чел из ЛА так любит русский язык, что прям как АС коверкает в угоду рифмы: "симметрические" ... Ну кто бы мог дойти!?

[grokfrog]

Спасибо за замечание.

Я не из ЛА, я из Москвы. Текст, как и в прошлый раз, в основном нейросеть писала, я только идею и фактуру давал. К сожалению, я не редактор и не поэт, у меня в школе по русскому твёрдая троечка была

«Симметрические» поправлю на нормальное «симметричная». Спасибо, что ткнул. Буду стараться внимательнее проверять.

[vvbymrf]

Насколько быстро работает интерфейс? Или до этого ещё не дошло.

[grokfrog]

Доброй ночи! ответ, на ваш комментарий ниже, мучался с разметкой, не туда написал)

[grokfrog]

Прогнал локальный 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 сообщений.

[grokfrog]

Спасибо всем за звезды на гите, сейчас расплачусь...