Thrift、Protocol Buffers、JSON、EJB、その他のパフォーマンス比較？

StackOverflow https://stackoverflow.com/questions/296650

質問

トランスポート/プロトコルソリューションを検討しており、さまざまなパフォーマンステストを実行しようとしていたので、コミュニティで既にこれを行っているかどうかを確認すると思いました：

LinuxでEJB3、Thrift、およびプロトコルバッファーを比較するさまざまなメッセージサイズのシリアル化/逆シリアル化だけでなく、単純なエコーサービスのサーバーパフォーマンステストを行った人はいますか？

主に言語はJava、C / C ++、Python、およびPHPです。

更新：私はまだこれに非常に興味があります。さらにベンチマークを行った人がいたら教えてください。また、 Thrift / Protocol Buffersと同等以上のパフォーマンスを発揮する圧縮されたJSON を示す非常に興味深いベンチマークです。この質問にもJSONを投げています。

役に立ちましたか？

解決

最新の比較は、 thrift-protobuf-compare プロジェクトwikiで入手できます。他の多くのシリアル化ライブラリが含まれています。

他のヒント

thriftという名前のオープンソースプロジェクトでいくつかのコードを書いている最中です-protobuf-compare protobufとthriftの比較。現時点では、シリアル化の側面はほとんど取り上げていませんが、さらに詳しく説明する予定です。結果（ Thrift および Protobuf ）については私のブログで説明しています。詳細については、後ほど追加します。 コードを見て、API、記述言語、生成されたコードを比較できます。より丸みを帯びた比較を達成するために貢献できてうれしいです。

この質問に興味があるかもしれません：＆quot; Thriftと最大の違いプロトコルバッファ？＆quot;

他の多くのデータ形式（xml、json、デフォルトのオブジェクトシリアル化、ヘシアン、プロプライエタリなもの）と、データバインディングタスク（読み取りと書き込みの両方）のライブラリ（jaxb、高速インフォセット、書き込み）、しかしth約のフォーマットは含まれていませんでした。複数のコンバーター（xmlなど）を含む形式のパフォーマンスは、非常に遅いものからかなり速いものまで、非常に大きなばらつきがありました。著者の主張と知覚されたパフォーマンスとの相関関係はかなり弱かった。特に、最もワイルドな主張をしたパッケージの場合。

それが価値があるのは、PBのパフォーマンスが誇張されていることです（通常はその作者ではなく、誰が書いたのかしか知らない人によって）。デフォルト設定では、最速のテキストxmlの代替に勝るものはありませんでした。最適化モード（これがデフォルトではない理由）では、最速のJSONパッケージに匹敵する、少し高速でした。ヘシアンもかなり高速で、テキスト形式のjsonでもありました。独自のバイナリ形式（ここでは名前はありません。社内で作成されました）が最も低速でした。 Javaオブジェクトのシリアル化は、大きなオブジェクトでは高速で、小さなオブジェクトではそれほど高速ではありませんでした（つまり、操作ごとの固定された高いnoverhead）。 PBメッセージサイズはコンパクトでしたが、すべてのトレードオフを考慮する必要があります（データは自己記述的ではありません：スキーマを失うと、データを失います;もちろん、インデックスと値型がありますが、必要に応じてフィールド名にリバースエンジニアリングします）、個人的には特定のユースケースにのみ選択します-インターフェース/フォーマットが変更されない（または非常にまれに）サイズに依存する密接に結合されたシステム。

これに対する私の意見は、（a）実装はしばしば（データ形式の）仕様よりも重要である、（b）エンドツーエンド、（異なる形式の）ベストオブブリードの違いは通常十分ではないということです選択を指示します。 つまり、ほとんどを使用して（または最高のツールサポートを備えた）好みのformat + API / lib / frameworkを選択し、最適な実装を見つけて、それが十分に速く動作するかどうかを確認する方が良いかもしれません。 そうでない場合（だけ！）、次善の策を検討してください。

ps。ここのEJB3がどうなるかはわかりません。たぶん、Javaシリアル化の単純なことですか？

「やること」の一番上にあるものの1つPBのリストは、Googleの内部プロトコルバッファパフォーマンスベンチマークを移植することです。ほとんどの場合、機密メッセージ形式を取得し、それらを完全に当たり障りのない形式に変換してから、データに対して同じことを行います。

それが完了したら、Thriftで同じメッセージを作成し、パフォーマンスを比較できると思います。

つまり、まだデータがありません-でも、できれば次の数週間で...

生のネットパフォーマンスが目標である場合、IIOPに勝るものはありません（RMI / IIOPを参照）。 可能な限り小さいフットプリント-バイナリデータのみで、マークアップはまったくありません。シリアライゼーション/デシリアライゼーションも非常に高速です。

IIOP（つまりCORBA）であるため、ほとんどすべての言語にバインディングがあります。

しかし、パフォーマンスはのみの要件ではないと思いますか？

IIOPに関するVladimirの論点をバックアップするために、ThriftとCORBAを比較するため、Googleベンチマークに関する追加情報を提供する興味深いパフォーマンステストがあります。 （Performance_TIDorb_vs_Thrift_morfeo.pdf //リンクは無効です） 調査から引用するには：

  
      
  • 節約は非常に効率的です   データ（操作としての基本タイプ   引数）
    •   
  • Thriftsトランスポートは、CORBAが中程度で、   大きなデータ（構造体および＆gt; complex   タイプ＆gt; 1キロバイト）。
    •   

パフォーマンスに関係しないもう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、およびプロトコルバッファーの統合について調査しました。

サーバー側： https://github.com/vlachenal/webservices-bench

クライアント側： https://github.com/vlachenal/webservices-bench-client

終了しておらず、パソコンで実行されています（テストを完了するためにサーバーに依頼する必要があります）...しかし、結果は次の場所で確認できます：

結論として：

  • Thriftは最高のパフォーマンスを提供し、使いやすいです
  • JSONコンテンツタイプを使用したRESTful Webサービスは、Thriftのパフォーマンスに非常に近く、「ブラウザをすぐに使用できます」とてもエレガントです（私の観点から）
  • SOAPのパフォーマンスは非常に低いですが、最高のデータ制御を提供します
  • Protocol Buffersのパフォーマンスは良好です... 3つの同時呼び出しまで...そしてその理由はわかりません。使用するのは非常に困難です。MapStructで動作させるために（今のところ）giveめ、Dozerで試していません。

プロジェクトは、プルリクエストを介して完了することができます（修正またはその他の結果のため）。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top