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

Question

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

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

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

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

• ноутбук: https://github.com/vlachenal/webservices-bench/blob/master/results.md
• Рабочий стол: https://github.com/vlachenal/webservices-bench/blob/master/results-desktop.md

Как вывод:

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

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