Буферы протокола, обрабатывающие очень большое строковое сообщение?

Question

Я наконец-то смог написать код буферов протокола поверх REST и провел некоторое сравнение с XStream, который мы сейчас используем.Все кажется великолепным, спотыкается только об одной вещи.

У нас очень большие сообщения в одном конкретном атрибуте, скажем что-то вроде этого

message Data {
   optional string datavalue=1;
}

Указанные выше данные являются чрезвычайно огромными текстовыми сообщениями.Размер составляет 512 КБ - 5 МБ.

Буферы протокола десериализуются очень хорошо, с превосходной производительностью по сравнению с XStream.Тем не менее, я замечаю, что когда я отправляю это сообщение по проводам (через REST), получение ответа заняло больше времени.Всегда вдвое дольше, чем XStream.Я думаю, что это может произойти из-за времени сериализации.

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

Я былинтересно, есть ли у кого-то мнение или, может быть, решение из моего дела выше?

Спасибо

Answer 1

Некоторое время назад я тестировал различные инструменты сериализации и заметил, что Java-библиотеке Protobuf понадобилось примерно в 1,7 раза больше времени для сериализации строк, чем java.io.DataOutputStream. Когда я посмотрел на это, мне показалось, что это связано со странным артефактом того, как JVM оптимизирует определенные пути кода. Однако в моем тесте XStream всегда был медленнее, даже с очень длинными строками.

Одна быстрая вещь - это совместимая с форматом библиотека Protostuff вместо библиотеки Google Protobuf. * ​​1006 *

Answer 2

Я помню, как читал где-то (пытаясь найти статью), что protobuf очень хорош, если у вас есть смесь двоичных и текстовых типов данных.Когда вы работаете исключительно с текстовыми данными, вы можете получить лучшую производительность и размер, сжав их.