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

StackOverflow https://stackoverflow.com/questions/296650

Вопрос

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

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

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

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

Это было полезно?

Решение

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я провел исследование интеграции Spring-Boot, картографов (ручных, Dozer и MapStruct), Thrift, REST, SOAP и протокольных буферов для своей работы.

Серверная часть: https://github.com/vlachenal/webservices-bench

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

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

В качестве заключения:

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top