G-FORCE
0.0G
разгон
← все разборы

Доска для команды разваливалась на плохом Wi-Fi


! Проблема

Совместная доска на WebSocket: несколько человек рисуют одновременно. При активном рисовании в сокет летели сотни событий в секунду — сервер захлёбывался, у клиентов появлялся лаг. А при обрыве интернета пользователь возвращался на пустую доску: всё нарисованное терялось.

Решение

Ввёл батчинг: координаты копятся в буфере и уходят пакетом раз в 40 мс — глазу разницы нет, а трафик падает в разы. Состояние комнаты перенёс в Redis, историю операций — в PostgreSQL, поэтому новый участник получает снапшот одним запросом, а не тысячу событий подряд. Добавил переподключение с экспоненциальной задержкой и очередь неотправленных действий на клиенте.

Как я к этому пришёл

Я тестировал на localhost, где сеть идеальна и задержка нулевая. Первый же человек с обычным Wi-Fi показал, насколько это далеко от реальности.

Первая проблема — объём. Событие mousemove срабатывает десятки раз в секунду, и каждое я честно отправлял на сервер. Четыре человека рисуют — и это уже сотни сообщений в секунду. Решение оказалось простым: не отправлять каждую точку, а копить их 40 миллисекунд и слать пачкой.

Вторая проблема — состояние. Я хранил историю доски в памяти процесса. Перезапуск сервера — и всё пропало. Redis решил вопрос общего состояния, PostgreSQL — вопрос долговременного хранения.

Третья, самая коварная — реконнект. Браузер сообщает о разрыве не сразу. Я добавил на клиент очередь: пока сокет закрыт, действия копятся локально и отправляются после восстановления связи. Переподключение с растущей задержкой, чтобы не долбить упавший сервер каждую секунду.

Доска держит одновременных участников без заметной задержки, трафик после батчинга упал примерно в 8 раз, а обрыв связи больше не стирает работу.

Вывод

Сеть — это не «просто отправить данные». Пока не протестируешь на плохом соединении, ты не знаешь, работает ли твой код.

Другие разборы