Agent perfomance

Проблемы с утечками памяти и производительностью:

Backend (Server)

1. WebSocket - нет очистки соединений при закрытии (log-server/index.ts) ◦ UDP сокеты создаются в цикле (строка 31), но нигде не сохраняются ссылки и не закрываются при shutdown ◦ Каждый UDP listener создает новые обработчики в памяти без возможности их удаления
2. Promise.all в readLogs без ограничения (access-logs/service.ts, строка 93) ◦ При обработке большого количества логов (logLines.map(async…)) создается массив промисов без ограничения параллелизма ◦ Может привести к перегрузке памяти при обработке тысяч строк одновременно
3. Promise.all в getContentTypeStats (metrics/service.ts, строка 151) ◦ Для каждого contentType выполняется дополнительный Redis запрос в Promise.all ◦ При большом количестве типов контента - множество параллельных запросов
4. Promise.all в getLatestTime (metrics/service.ts, строка 307) ◦ Для каждого origin выполняется Redis запрос без ограничения параллелизма ◦ Потенциально десятки одновременных запросов к Redis
5. getUsersInfo - неэффективный цикл с Redis запросами (metrics/service.ts, строки 392-443) ◦ Два Redis запроса (FT.SEARCH) для каждого пользователя в цикле ◦ При наличии сотен пользователей - сотни последовательных запросов
6. setInterval для cleanupDeadConnections никогда не очищается (ws/index.ts, строка 16) ◦ Создается глобальный interval, но нет механизма его остановки при shutdown
7. ParserService.getAll при каждом UDP пакете (log-server/index.ts, строка 39) ◦ При каждом входящем UDP пакете выполняется FT.SEARCH по всем origins ◦ Высокая частота запросов при активном трафике
8. Отсутствие лимита на размер Map в WsService (ws.service.ts, строка 9) ◦ connectedClients Map может расти бесконечно при подключениях ◦ Нет явного ограничения на количество клиентов
9. Redis keys() без паттерна (access-logs/service.ts, строки 13-15) ◦ keys(“log:access:*”) - блокирующая операция, сканирует всю БД ◦ При большом количестве ключей блокирует Redis

Frontend (Web)

10. SharedWorker connections array растет бесконечно (access.worker.ts, строка 10) ◦ Новые порты добавляются в массив connections (строка 107) ◦ Нет удаления отключенных портов из массива
11. WebSocket reconnect без экспоненциальной задержки (access.worker.ts, строка 76) ◦ При обрыве соединения переподключение через 1 секунду ◦ При проблемах с сервером может создать flood запросов
12. shallowRef для больших данных без очистки (stores/access.ts, stats.ts) ◦ Данные накапливаются в shallowRef без явной очистки ◦ При долгой работе приложения может накопиться большой объем данных
13. JSON.parse вызывается дважды (stores/access.ts, строки 26-27) ◦ Сначала парсится event.data, затем data.data ◦ Неэффективно и может вызвать проблемы с памятью при больших данных

Redis

14. Отсутствие пайплайнов для множественных операций ◦ В readLogs каждый hset выполняется отдельно (строка 89) ◦ Можно использовать pipeline для batch операций
15. expire вызывается отдельно после каждого hset ◦ Две команды вместо одной с EXAT параметром