У меня есть связь между двумя процессами Java, обе стороны используют Netty.Сторона декодирования использует ReplayingDecoder и использует его для десериализации более сложного типа сообщений.
Большинство сообщений довольно малы.Однако сегодня я обнаружил проблему производительности с большими сообщениями (~ 4 МБ), которая возникает очень редко.
Я уже предположил следующее
- Сообщения не должны быть 4 МБЯ могу сделать их меньше
- ReplayingDecoder, вероятно, не лучший выбор для обработки больших сообщений, подобных этому, без какого-либо заголовка длины для сохранения анализа снова и снова
За исключением Iне был уверен, почему это было так медленно.Я потратил несколько минут на передачу сообщения с одной стороны на другую.
При записи выполняется следующее
- Создание динамического буфера
- Запись всего сообщениядля буферизации
- Вызовите channel.write () один раз с буфером
, который выглядит достаточно быстрым (наблюдая, когда будущее завершится).Размер сообщения составляет около 4 МБ.
Глядя на сторону декодирования, я вижу, что каждые несколько секунд он попадает в мой обработчик, когда он пытается что-то проанализировать, выдает, воспроизводит, ждет больше данных и т. Д.
Однако я видел только размер буфера, показывающий, что доступные данные увеличивались примерно на 50 Кб каждый раз, когда вызывался обработчик (каждую секунду или около того).Я бы ожидал, что буфер заполнится гораздо быстрее, чем этот.
Я нахожусь в локальной сети, фактически два процесса на одном компьютере, использующие адрес обратной связи для подключения к скорости сети, не должны быть основным фактором.
Это ожидаемое поведение?Мой повторный процесс синтаксического анализа, который будет блокировать работу обработчика и всего, что сериализовано с ним, и, возможно, заполнение буфера так быстро, как я ожидал?
Я использую Netty 3.1.1.GA (довольностарый, может обновиться, чтобы проверить, возможно ли что-то улучшить)