Lorawan-stack: Просмотр данных замедляется и зависает после получения большого количества событий

Проблема, вероятно, вызвана значительным заполнением хранилища redux, когда консоль подписана на источник событий. Особенно после обновления брокера пакетов он будет получать много данных на каждое событие, что легко поглощает память.

Redux store, безусловно, связан с этим, но основная проблема - это рендеринг. После https://github.com/TheThingsNetwork/lorawan-stack/pull/2477#discussion_r421182736 я снял ограничение на количество событий, отображаемых в представлении событий.

Ваше решение выглядит нормально, но на самом деле localStorage требует некоторых экспериментов.

Итак, немного поработав над этим, я думаю, что решение здесь тройное:

1. Выполните рефакторинг общей структуры компонентов событий, которая в настоящее время вложена таким образом, что очень сложно поддерживать и оптимизировать производительность (мы используем клонирование элементов и рендеринг реквизитов, что делает невозможным использование мемоизации элементов списка)
2. Используйте модуль виртуализации, например react-window чтобы отображать только те элементы списка, которые в данный момент видны.
3. Изучите другие способы хранения данных событий, как описано в OP (я поэкспериментирую с производительностью после введения 1. и 2., поскольку, как упоминалось в @bafonins , проблемы с производительностью в основном связаны с рендерингом)

1. Вы можете добавить мемоизацию к функции рендеринга ~ компоненту события верхнего уровня ~.
2. Это не сработает. Я пробовал использовать виртуализированные списки при реализации первой версии компонента событий. В основном из-за динамических высот.

К сожалению, эта проблема не устранена. Хотя представления событий теперь могут обрабатывать большую нагрузку, но все еще существует определенный порог количества событий и частоты, которые вызовут задержки и зависания.

Я повторно введу максимальное количество событий в качестве быстрого средства, пока мы не сможем настроить это дальше.

Это в процессе?

Это больше не происходит. Мне пришлось закрыть две попытки улучшить это, потому что нельзя было проверить, помогли ли эти решения. Ситуация значительно улучшилась после виртуализации списков с помощью # 3229, но все еще есть точка отказа, когда представление событий получает тысячи событий. Я как-то пропустил открытие PR, которое решит эту проблему, ограничив количество событий, отображаемых в консоли. Сделаю это сейчас.

Я как-то пропустил открытие PR, которое решит эту проблему, ограничив количество событий, отображаемых в консоли. Сделаю это сейчас.

-> # 3470

Кроме того, эти два комментария дают некоторое представление о том, что я пытался сделать и какие проблемы у меня были:

https://github.com/TheThingsNetwork/lorawan-stack/pull/3329#issuecomment -712410891

https://github.com/TheThingsNetwork/lorawan-stack/pull/3330#issuecomment -712937573

Надеюсь, это поможет в будущих попытках более тщательного решения проблемы.

Повторное открытие, поскольку проблема все еще остается при отображении событий для приложений с ~ 50+ конечными устройствами (это зависит от того, как часто конечные устройства отправляют или получают данные). В этом комментарии уже есть несколько идей, как решить эту проблему.

Давайте воспользуемся этой веткой, чтобы обсудить возможные другие способы решения этой проблемы. См. Также https://github.com/TheThingsNetwork/lorawan-stack/pull/3329#issuecomment -712410891 и https://github.com/TheThingsNetwork/lorawan-stack/pull/3330#issuecomment -712937573

@kschiffer какой здесь статус?

Это сложно. Правильное решение этой проблемы заблокировано на # 3817. Промежуточное исправление описано здесь https://github.com/TheThingsNetwork/lorawan-stack/issues/2231#issuecomment -779659836.

Чтобы добавить это, нам нужно иметь возможность фильтровать потоки событий по типам событий, что является одной из вещей, которые будут добавлены сервером событий TheThingsIndustries / lorawan-stack # 1804.

Так что в любом случае быстрого решения нет. Единственное, что я могу назвать предварительным исправлением, - это автоматическое закрытие потока событий и отображение пояснительного сообщения, если он достигает порогового значения событий в секунду.

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