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



3 Answers

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

Question

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

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

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

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




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

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

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

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




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

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

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




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

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

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

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

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

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

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




Related