it-swarm.com.ru

Сравнение производительности Thrift, Protocol Buffers, JSON, EJB, других?

Мы изучаем транспортные/протокольные решения и собирались провести различные тесты производительности, поэтому я решил проверить с сообществом, уже сделали ли они это:

Кто-нибудь делал тесты производительности сервера для простых эхо-сервисов, а также сериализации/десериализации для различных размеров сообщений, сравнивая EJB3, Thrift и Protocol Buffers в Linux?

Основными языками будут Java, C/C++, Python и PHP.

Обновление: я все еще очень заинтересован в этом, если кто-нибудь сделал какие-либо дополнительные тесты, пожалуйста, дайте мне знать. Кроме того, очень интересный тест, показывающий сжатый JSON, работающий аналогично/лучше, чем Thrift/Protocol Buffers , поэтому я добавлю JSON и в этот вопрос.

65
Parand

Последнее сравнение доступно здесь в thrift-protobuf-compare project wiki. Он включает в себя много других библиотек сериализации.

53
Eishay Smith

Я нахожусь в процессе написания некоторого кода в проекте с открытым исходным кодом под названием thrift-protobuf-compare сравнение между protobuf и thrift. На данный момент он охватывает несколько аспектов сериализации, но я намерен охватить больше. Результаты (для Thrift и Protobuf ) обсуждаются в моем блоге, я добавлю больше, когда доберусь до него . Вы можете посмотреть код для сравнения API, язык описания и сгенерированный код. Я буду рад иметь вклады для достижения более округленного сравнения. 

15
eishay

Вы можете быть заинтересованы в этом вопросе: "Самые большие различия между Thrift и Protocol Buffers?"

8
user38123

Я проверил производительность PB с рядом других форматов данных (xml, json, сериализация объектов по умолчанию, гессиан, один проприетарный) и библиотеками (jaxb, fast infoset, рукописный) для задачи связывания данных (как чтение, так и запись), но формат Thrift не был включен. Производительность для форматов с несколькими конвертерами (например, xml) сильно отличалась от очень медленной до чертовски быстрой. Корреляция между претензиями авторов и предполагаемым исполнением была довольно слабой. Особенно это касается упаковок, которые предъявляют самые смелые требования.

Что бы это ни стоило, я обнаружил, что производительность PB немного завышена (обычно не ее авторами, а теми, кто знает только, кто ее написал). С настройками по умолчанию он не побил быструю текстовую альтернативу xml. С оптимизированным режимом (почему это не по умолчанию?) Он был немного быстрее, сравнимым с самым быстрым пакетом JSON. Гессиан был довольно быстр, текстовый JSON тоже. Правильный двоичный формат (без названия, это была компания внутри компании) был самым медленным. Сериализация Java-объектов была быстрой для больших сообщений, в меньшей степени - для небольших объектов (т. Е. С высоким фиксированным значением для каждой операции) . Размер PB-сообщения был компактным, но с учетом всех компромиссов, которые вы должны сделать (данные не являются самостоятельными описательный: если вы потеряете схему, вы потеряете данные; конечно, есть индексы и типы значений, но из того, что у вас есть обратный инжиниринг обратно к именам полей, если хотите), я лично выбрал бы его только для конкретных случаев использования - - чувствительная к размеру, тесно связанная система, в которой интерфейс/формат никогда (или очень редко) не изменяется.

Мое мнение в этом заключается в том, что (а) реализация часто имеет большее значение, чем спецификация (формата данных), (б) сквозные различия между лучшими в своем классе (для разных форматов) обычно недостаточно велики, чтобы диктовать выбор .. То есть вам лучше выбрать формат + API/lib/framework, который вам больше всего нравится (или имеет лучшую поддержку инструментов), найти лучшую реализацию и посмотреть, работает ли он достаточно быстро . If ( и только если!) нет, рассмотрите следующую лучшую альтернативу.

пс. Не уверен, что EJB3 здесь будет. Может быть, просто сериализация Java?

7
StaxMan

Одна из вещей, стоящих в верхней части моего списка «дел» для PB, заключается в портировании внутреннего эталонного теста производительности Google Buffer протокола - это в основном случай принятия конфиденциальных форматов сообщений и превращения их в совершенно простые, а затем то же самое для данные.

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

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

4
Jon Skeet

Если целевая чистая производительность является целью, то ничто не сравнится с IIOP (см. RMI/IIOP) . Наименьший возможный след - только двоичные данные, без разметки вообще. Сериализация/десериализация тоже очень быстрая.

Поскольку это IIOP (то есть CORBA), почти все языки имеют привязки.

Но я предполагаю, что производительность не является требованием only, верно?

4
Vladimir Dyuzhev

Чтобы подтвердить точку зрения Владимира о IIOP, вот интересный тест производительности, который должен дать некоторую дополнительную информацию о тестах Google, так как он сравнивает Thrift и CORBA. (Performance_TIDorb_vs_Thrift_morfeo.pdf // ссылка больше не действительна) Цитата из исследования:

  • Экономия очень эффективна с маленькими данные (основные типы как операции аргументы)
  • Транспортные сбросы не так эффективны, как CORBA со средним и большие данные (структура и> сложные типы> 1 килобайт).

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

Интересно, что Thrift IDL близко соответствует CORBA IDL, Nice. Я не использовал Thrift, это выглядит интересно, особенно для небольших сообщений, и одна из целей разработки была для менее громоздкой установки, так что это другие преимущества Thrift. Тем не менее, у CORBA плохой рэп, есть много отличных реализаций, таких как, например, omniORB , в которых есть привязки для Python, которые легко установить и использовать.

Отредактировано: ссылка Thrift и CORBA больше не действительна, но я нашел другую полезную статью из CERN. Они оценивали замены для своей системы CORBA, и, в то время как они оценивали Thrift , они в конечном итоге пошли с ZeroMQ. Хотя Thrift показал самые быстрые результаты в своих тестах производительности, со скоростью 9000 мсг/с против 8000 (ZeroMQ) и 7000+ RDA (на основе CORBA), они решили не тестировать Thrift дополнительно из-за других проблем, в частности:

Это все еще незрелый продукт с ошибочной реализацией

3
michaelok

Я выполнил исследование по интеграции Spring-boot, mappers (manual, Dozer и MapStruct), Thrift, REST, SOAP и Protocol Buffers для своей работы.

На стороне сервера: https://github.com/vlachenal/webservices-bench

Клиентская сторона: https://github.com/vlachenal/webservices-bench-client

Он не завершен и был запущен на моих персональных компьютерах (мне нужно запросить серверы для завершения тестов) ... но с результатами можно ознакомиться на:

В заключение:

  • Thrift предлагает лучшую производительность и прост в использовании
  • Веб-сервис RESTful с типом контента JSON довольно близок к производительности Thrift, «готов к использованию в браузере» и довольно элегантен (с моей точки зрения)
  • SOAP имеет очень низкую производительность, но предлагает лучший контроль данных
  • Протокол Buffers имеет хорошую производительность ... до 3 одновременных вызовов ... и я не знаю почему. Его очень сложно использовать: я отказываюсь (пока), чтобы заставить его работать с MapStruct, и я не пытаюсь с Dozer.

Проекты могут быть завершены с помощью запросов извлечения (для исправлений или других результатов).

0
user4047208