Thrift、Protocol Buffers、JSON、EJB、その他のパフォーマンス比較？
トランスポート/プロトコルソリューションを検討しており、さまざまなパフォーマンステストを実行しようとしていたので、すでにこれを行っているかどうかをコミュニティに確認すると思いました。
LinuxでEJB3、Thrift、およびプロトコルバッファーを比較するさまざまなメッセージサイズのシリアル化/逆シリアル化だけでなく、単純なエコーサービスのサーバーパフォーマンステストを行った人はいますか？
主に言語は、Java、C/C++、Python、およびPHPになります。
更新：私はまだこれに非常に興味があります。誰かがさらにベンチマークを行った場合はお知らせください。また、非常に興味深いベンチマーク 圧縮されたJSONのパフォーマンスはThrift/Protocol Buffersよりも同等/優れています なので、この質問にもJSONを投げています。
thrift-protobuf-compare プロジェクトwikiで最新の比較を利用できます。他の多くのシリアル化ライブラリが含まれています。
私は thrift-protobuf-compareという名前のオープンソースプロジェクト protobufとthriftを比較するコードを書いている最中です。今のところ、それはいくつかのシリアライゼーションの側面をカバーしていますが、私はもっとカバーするつもりです。結果（ Thrift および Protobuf について）は私のブログで説明されていますが、さらに詳しく説明します。コードを見て、API、記述言語、生成されたコードを比較できます。より丸みを帯びた比較を達成するために貢献できてうれしいです。
他の多くのデータ形式（xml、json、デフォルトのオブジェクトシリアル化、ヘシアン、プロプライエタリなもの）とデータバインディングタスク（読み書き両方）のライブラリ（jaxb、高速インフォセット、手書き）でPBのパフォーマンスをテストしました。しかし、rif約の形式は含まれていませんでした。複数のコンバーター（xmlなど）を使用した形式のパフォーマンスは、非常に遅いものからかなり速いものまで、非常に大きなばらつきがありました。著者の主張と知覚されたパフォーマンスとの相関関係はかなり弱かった。特に、最もワイルドな主張をしたパッケージの場合。
それが価値があることに関して、私はPBのパフォーマンスが誇張されていることを見つけました（通常はその作者ではなく、誰が書いたのかを知っている他の人によって）。デフォルト設定では、最速のテキストxmlの代替に勝るものはありませんでした。最適化モード（これがデフォルトではない理由）では、最速のJSONパッケージに匹敵する、少し高速でした。ヘシアンもかなり高速で、テキスト形式のjsonでもありました。独自のバイナリ形式（ここでは名前はありません。社内で作成されました）が最も低速でした。 Javaオブジェクトのシリアル化は、大きなオブジェクトの場合は高速で、小さなオブジェクトの場合はそれほど高速ではありません（つまり、操作ごとの固定された高い固定値）。PBメッセージサイズはコンパクトでしたが、すべてのトレードオフを考慮する必要がありました（データは自己記述的ではありません：スキーマを失うと、データを失います;もちろん、インデックスと値タイプがありますが、リバースエンジニアが持っているものから必要に応じてフィールド名に戻る）、私は個人的にのみ選択します特定のユースケース向け-インターフェース/フォーマットが変更されない（または非常にまれ）サイズ依存の密接に結合されたシステム。
これに対する私の意見は、（a）実装はしばしば（データ形式の）仕様よりも重要である、（b）エンドツーエンド、（異なる形式の）ベストオブブリードの違いは通常、選択。つまり、ほとんどを使用して（またはツールサポートが最適な）format + API/lib/frameworkを選択し、最適な実装を見つけて、それが十分に速く動作するかどうかを確認する方が良い場合があります。そうでない場合（だけ！）、次善の策を検討してください。
追伸ここにあるEJB3がどうなるかわかりません。 Javaシリアライゼーション？
この質問に興味があるかもしれません： "ThriftとProtocol Buffersの最大の違い？"
私のPBの「やること」リストの一番上にあるものの1つは、Googleの内部Protocol Bufferパフォーマンスベンチマークを移植することです。これは、ほとんどが機密メッセージ形式を取り込んで、それらを完全に当たり障りのない形式に変換し、データ。
それが完了したら、Thriftで同じメッセージを作成し、パフォーマンスを比較できると思います。
言い換えると、まだデータがありません-しかし、できれば次の数週間で...
生のネットパフォーマンスが目標である場合、IIOPに勝るものはありません（RMI/IIOPを参照）。可能な限り小さいフットプリント-バイナリデータのみで、マークアップはまったくありません。シリアル化/逆シリアル化も非常に高速です。
IIOP（つまりCORBA）であるため、ほとんどすべての言語にバインディングがあります。
しかし、パフォーマンスはonlyの要件ではないと思いますか？
IIOPについてのVladimirの論点をバックアップするために、ThriftとCORBAを比較しているため、Googleベンチマークに関する追加情報を提供する興味深いパフォーマンステストがあります。 （Performance_TIDorb_vs_Thrift_morfeo.pdf //リンクは無効です）調査から引用するには：
- Thriftは小さなデータ（操作引数としての基本型）で非常に効率的です
- Thriftsトランスポートは、中規模および大規模データ（構造および>複合型> 1キロバイト）を使用するCORBAほど効率的ではありません。
パフォーマンスに関係しないもう1つの奇妙な制限は、Thriftが構造体としていくつかの値のみを返すことに制限されていることです。ただし、これはおそらくパフォーマンスと同様におそらく改善できます。
Thrift IDLがCORBA IDLのニースと密接に一致しているのは興味深いことです。私はThriftを使用していません。特にメッセージが小さい場合は面白そうですが、設計目標の1つはインストールの面倒さを抑えることでした。これらはThriftの他の利点です。とはいえ、CORBAには悪いラップがあり、たとえば omniORB のような優れた実装が数多くあります。これには、Pythonのバインディングがあり、インストールと使用が簡単です。
編集：ThriftとCORBAのリンクは無効になりましたが、CERNから別の有用な論文を見つけました。彼らはCORBAシステムの代替品を評価し、 評価されたThrift でしたが、最終的にZeroMQを使用しました。 Thriftはパフォーマンステストで9000 msg/sec対8000（ZeroMQ）および7000+ RDA（CORBAベース）で最速を実行しましたが、特に他の問題のためにさらにThriftをテストしないことを選択しました。
まだバグのある実装の未熟な製品です
私は自分の仕事のために、スプリングブート、マッパー（手動、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は最高のパフォーマンスを提供し、使いやすい
- JSONコンテンツタイプを使用したRESTful Webサービスは、Thriftのパフォーマンスに非常に近く、「すぐに使用できるブラウザー」であり、非常にエレガントです（私の観点から）
- SOAPのパフォーマンスは非常に劣りますが、最高のデータ制御を提供します
- Protocol Buffersのパフォーマンスは良好です... 3つの同時呼び出しまで...そしてその理由はわかりません。使用するのは非常に困難です。MapStructで動作させるために（今のところ）あきらめ、Dozerでは試しません。
プロジェクトは、プルリクエスト（修正またはその他の結果）を介して完了することができます。