Сравнение производительности Thrift, протокольных буферов, JSON, EJB, других?

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

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

В первую очередь языки будут Java, C/С++, Python и PHP.

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Так как это IIOP (это CORBA), почти все языки имеют привязки.

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

Ответ 7

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

Сбережения очень эффективны с небольшими данные (основные типы в качестве операции аргументы)

Транспорта транспортов не так эффективны, как CORBA со средними и большие данные (struct and > complex типы > 1 килобайт).

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

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

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

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

Ответ 8

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

Серверная сторона: 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 webservice с типом контента JSON довольно близок к производительности Thrift, "браузер готов к использованию" и довольно элегантен (с моей точки зрения).
SOAP имеет очень низкую производительность, но обеспечивает лучший контроль данных.
Буферы протоколов имеют хорошую производительность... до 3 одновременных вызовов... и я не знаю почему. Это очень сложно использовать: я отказываюсь (пока), чтобы он работал с MapStruct, и я не пытаюсь использовать Dozer.

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