сравнение производительности thrift, protocol buffers, json, ejb, других?

<p>мы изучаем транспортные/протокольные решения и собирались провести различные тесты производительности, поэтому я решил проверить с сообществом, уже сделали ли они это:</p><p>кто-нибудь делал тесты производительности сервера для простых эхо-сервисов, а также сериализации/десериализации для различных размеров сообщений, сравнивая ejb3, thrift и protocol buffers в linux?</p><p>основными языками будут java, c/c++, python и php.</p><p>обновление: я все еще очень заинтересован в этом, если кто-нибудь сделал какие-либо дополнительные тесты, пожалуйста, дайте мне знать. кроме того, очень интересный тест, показывающий <a href="http://bouncybouncy.net/ramblings/posts/more\_on\_json\_vs\_thrift\_and\_protocol\_buffers/">сжатый json, работающий аналогично/лучше, чем thrift/protocol buffers</a> , поэтому я добавлю json и в этот вопрос.</p>

<p>последнее сравнение доступно здесь в <a href="https://github.com/eishay/jvm-serializers/wiki/">thrift-protobuf-compare</a> project wiki. он включает в себя много других библиотек сериализации.</p>

<p>я нахожусь в процессе написания некоторого кода в <a href="http://code.google.com/p/thrift-protobuf-compare/">проекте с открытым исходным кодом под названием thrift-protobuf-compare</a> сравнение между protobuf и thrift. на данный момент он охватывает несколько аспектов сериализации, но я намерен охватить больше. результаты (для <a href="http://eishay.blogspot.com/search/label/thrift">thrift</a> и <a href="http://eishay.blogspot.com/search/label/protobuf">protobuf</a> ) обсуждаются в моем блоге, я добавлю больше, когда доберусь до него . вы можете посмотреть код для сравнения api, язык описания и сгенерированный код. я буду рад иметь вклады для достижения более округленного сравнения. </p>

<p>вы можете быть заинтересованы в этом вопросе: <a href="https://stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers">"самые большие различия между thrift и protocol buffers?"</a> </p>

<p>я проверил производительность pb с рядом других форматов данных (xml, json, сериализация объектов по умолчанию, гессиан, один проприетарный) и библиотеками (jaxb, fast infoset, рукописный) для задачи связывания данных (как чтение, так и запись), но формат thrift не был включен. производительность для форматов с несколькими конвертерами (например, xml) сильно отличалась от очень медленной до чертовски быстрой. корреляция между претензиями авторов и предполагаемым исполнением была довольно слабой. особенно это касается упаковок, которые предъявляют самые смелые требования.</p><p>что бы это ни стоило, я обнаружил, что производительность pb немного завышена (обычно не ее авторами, а теми, кто знает только, кто ее написал). с настройками по умолчанию он не побил быструю текстовую альтернативу xml. с оптимизированным режимом (почему это не по умолчанию?) он был немного быстрее, сравнимым с самым быстрым пакетом json. гессиан был довольно быстр, текстовый json тоже. правильный двоичный формат (без названия, это была компания внутри компании) был самым медленным. сериализация java-объектов была быстрой для больших сообщений, в меньшей степени - для небольших объектов (т. е. с высоким фиксированным значением для каждой операции) . размер pb-сообщения был компактным, но с учетом всех компромиссов, которые вы должны сделать (данные не являются самостоятельными описательный: если вы потеряете схему, вы потеряете данные; конечно, есть индексы и типы значений, но из того, что у вас есть обратный инжиниринг обратно к именам полей, если хотите), я лично выбрал бы его только для конкретных случаев использования - - чувствительная к размеру, тесно связанная система, в которой интерфейс/формат никогда (или очень редко) не изменяется.</p><p>мое мнение в этом заключается в том, что (а) реализация часто имеет большее значение, чем спецификация (формата данных), (б) сквозные различия между лучшими в своем классе (для разных форматов) обычно недостаточно велики, чтобы диктовать выбор .. то есть вам лучше выбрать формат + api/lib/framework, который вам больше всего нравится (или имеет лучшую поддержку инструментов), найти лучшую реализацию и посмотреть, работает ли он достаточно быстро . if ( и только если!) нет, рассмотрите следующую лучшую альтернативу.</p><p>пс. не уверен, что ejb3 здесь будет. может быть, просто сериализация java?</p>

<p>одна из вещей, стоящих в верхней части моего списка «дел» для pb, заключается в портировании внутреннего эталонного теста производительности google buffer протокола - это в основном случай принятия конфиденциальных форматов сообщений и превращения их в совершенно простые, а затем то же самое для данные.</p><p>когда это будет сделано, я представлю, что вы можете создавать те же сообщения в thrift, а затем сравнивать производительность.</p><p>другими словами, у меня пока нет данных для вас - но, надеюсь, в ближайшие пару недель ...</p>

<p>если целевая чистая производительность является целью, то ничто не сравнится с iiop (см. rmi/iiop) . наименьший возможный след - только двоичные данные, без разметки вообще. сериализация/десериализация тоже очень быстрая.</p><p>поскольку это iiop (то есть corba), почти все языки имеют привязки.</p><p>но я предполагаю, что производительность не является требованием <strong>only</strong>, верно?</p>

<p>чтобы подтвердить точку зрения владимира о iiop, вот интересный тест производительности, который должен дать некоторую дополнительную информацию о тестах google, так как он сравнивает thrift и corba. (performance\_tidorb\_vs\_thrift\_morfeo.pdf // ссылка больше не действительна) цитата из исследования:</p><blockquote> <ul> <li>экономия очень эффективна с маленькими данные (основные типы как операции аргументы)</li> <li>транспортные сбросы не так эффективны, как corba со средним и большие данные (структура и> сложные типы> 1 килобайт).</li> </ul> </blockquote><p>другое странное ограничение, не связанное с производительностью, заключается в том, что thrift ограничен возвратом только нескольких значений в виде структуры - хотя это, как и производительность, наверняка можно улучшить. </p><p>интересно, что thrift idl близко соответствует corba idl, nice. я не использовал thrift, это выглядит интересно, особенно для небольших сообщений, и одна из целей разработки была для менее громоздкой установки, так что это другие преимущества thrift. тем не менее, у corba плохой рэп, есть много отличных реализаций, таких как, например, <a href="http://omniorb.sourceforge.net/">omniorb</a> , в которых есть привязки для python, которые легко установить и использовать.</p><p>отредактировано: ссылка thrift и corba больше не действительна, но я нашел другую полезную статью из cern. они оценивали замены для своей системы corba, и, в то время как они <a href="http://zeromq.wdfiles.com/local--files/intro%3aread-the-manual/middleware%20trends%20and%20market%20leaders%202011.pdf">оценивали thrift</a> , они в конечном итоге пошли с zeromq. хотя thrift показал самые быстрые результаты в своих тестах производительности, со скоростью 9000 мсг/с против 8000 (zeromq) и 7000+ rda (на основе corba), они решили не тестировать thrift дополнительно из-за других проблем, в частности:</p><blockquote> <p>это все еще незрелый продукт с ошибочной реализацией</p> </blockquote>

<p>я выполнил исследование по интеграции spring-boot, mappers (manual, dozer и mapstruct), thrift, rest, soap и protocol buffers для своей работы.</p><p>на стороне сервера: <a href="https://github.com/vlachenal/webservices-bench">https://github.com/vlachenal/webservices-bench</a> </p><p>клиентская сторона: <a href="https://github.com/vlachenal/webservices-bench-client">https://github.com/vlachenal/webservices-bench-client</a> </p><p>он не завершен и был запущен на моих персональных компьютерах (мне нужно запросить серверы для завершения тестов) ... но с результатами можно ознакомиться на:</p><ul> <li>портативный компьютер: <a href="https://github.com/vlachenal/webservices-bench/blob/master/results.md">https://github.com/vlachenal/webservices-bench/blob/master/results.md</a> </li> <li>рабочий стол: <a href="https://github.com/vlachenal/webservices-bench/blob/master/results-desktop.md">https://github.com/vlachenal/webservices-bench/blob/master/results-desktop.md</a> </li> </ul><p>в заключение:</p><ul> <li>thrift предлагает лучшую производительность и прост в использовании</li> <li>веб-сервис restful с типом контента json довольно близок к производительности thrift, «готов к использованию в браузере» и довольно элегантен (с моей точки зрения)</li> <li>soap имеет очень низкую производительность, но предлагает лучший контроль данных</li> <li>протокол buffers имеет хорошую производительность ... до 3 одновременных вызовов ... и я не знаю почему. его очень сложно использовать: я отказываюсь (пока), чтобы заставить его работать с mapstruct, и я не пытаюсь с dozer.</li> </ul><p>проекты могут быть завершены с помощью запросов извлечения (для исправлений или других результатов).</p>