トランスポート/プロトコルソリューションを検討しており、さまざまなパフォーマンステストを実行しようとしていたので、コミュニティがすでにこれを実行しているかどうかを確認したいと思いました。
Linux上のEJB3、Thrift、およびProtocol Buffersを比較して、単純なエコーサービスのサーバーパフォーマンステストや、さまざまなメッセージサイズのシリアル化/逆シリアル化を行った人はいますか？
主な言語は、Java、C / C ++、Python、およびPHPです。
更新：私はまだこれに非常に興味があります。誰かがさらにベンチマークを行った場合は、私に知らせてください。また、圧縮されたJSONがThrift / Protocol Buffersと同様の/優れたパフォーマンスを示していることを示す非常に興味深いベンチマークなので、この質問にもJSONを投入しています。
最新の比較は、thrift-protobuf-compareプロジェクト wiki で入手できます。他の多くのシリアル化ライブラリが含まれています。
私は、protobuf と thrift を比較するthrift-protobuf-compare という名前のオープン ソース プロジェクトでコードを書いているところです。今のところ、シリアライゼーションの側面はほとんどカバーしていませんが、もっとカバーするつもりです。結果 ( ThriftおよびProtobufの場合) はブログで説明されています。コードを見て、API、記述言語、および生成されたコードを比較できます。より丸みを帯びた比較を実現するための貢献があれば幸いです。
この質問に興味があるかもしれません：「ThriftとProtocol Buffersの最大の違いは？」
データバインディングタスク（読み取りと書き込みの両方）のために、他の多くのデータ形式（xml、json、デフォルトオブジェクトシリアル化、ヘシアン、1つの独自のもの）とライブラリ（jaxb、高速情報セット、手書き）を使用してPBのパフォーマンスをテストしました。しかし、thrift のフォーマットは含まれていませんでした。複数のコンバーター (xml など) を使用する形式のパフォーマンスには、非常に遅いものからかなり速いものまで、非常に大きなばらつきがありました。著者の主張と知覚されたパフォーマンスとの相関関係はかなり弱かった. 特に、大胆な主張をしたパッケージについてはそうです。
価値のあるものとして、私は PB のパフォーマンスが少し誇大宣伝されていることを発見しました (通常、その作成者によるものではなく、誰が書いたかしか知らない他の人によるものです)。デフォルト設定では、最速のテキスト xml 代替に勝るものはありませんでした。最適化モード (なぜこれがデフォルトではないのですか?) では、最速の JSON パッケージに匹敵するほど高速でした。Hessian はかなり高速で、テキストの json もありました。独自のバイナリ形式 (名前はありません。社内用です) が最も遅かったです。Java オブジェクトのシリアライゼーションは、大きなメッセージの場合は高速でしたが、小さなオブジェクトの場合は高速でした (つまり、操作ごとに固定されたノーバーヘッドが高い)。PB のメッセージ サイズはコンパクトでしたが、すべてのトレードオフを考えると (データは自己記述的ではありません。スキーマを失うと、データが失われます。もちろん、インデックスと値の型がありますが、持っているものから必要に応じてフィールド名に戻すリバース エンジニアリング)、
これに関する私の意見は、(a) 実装は (データ形式の) 仕様よりも重要であることが多い、(b) エンドツーエンドの最善の組み合わせ (異なる形式の場合) の違いは、通常、選択。つまり、最もよく使用する (または最高のツール サポートがある) フォーマット + API/lib/フレームワークを選択し、最適な実装を見つけて、それが十分に高速に動作するかどうかを確認する方がよい場合があります。そうでない場合 (およびその場合のみ!)、次善の策を検討してください。
ps。ここでの EJB3 が何であるかはわかりません。単純な Java シリアライゼーションではないでしょうか。
生のネット パフォーマンスが目標である場合、IIOP に勝るものはありません (RMI/IIOP を参照)。可能な限り最小のフットプリント -- バイナリ データのみで、マークアップは一切ありません。シリアライゼーション/デシリアライゼーションも非常に高速です。
IIOP (つまり CORBA) であるため、ほとんどすべての言語にバインディングがあります。
しかし、パフォーマンスだけが要件ではないと思いますよね？
PBの「やること」リストの一番上にあることの1つは、Googleの内部プロトコルバッファパフォーマンスベンチマークを移植することです。これは主に、機密メッセージ形式を取得して完全に無味乾燥な形式に変換し、同じことを行う場合です。データ。
それが終わったら、Thriftで同じメッセージを作成して、パフォーマンスを比較できると思います。
言い換えれば、私はまだあなたのためのデータを持っていません-しかし、うまくいけば、次の数週間で...
IIOP に関する Vladimir の主張を裏付けるために、Thrift と CORBA を比較するため、Google ベンチマークに関する追加情報を提供する興味深いパフォーマンス テストを次に示します。(Performance_TIDorb_vs_Thrift_morfeo.pdf // リンクは無効になっています) 研究から引用するには:
- Thrift は小さなデータ (操作引数としての基本型) で非常に効率的です
- Thrifts トランスポートは、中規模および大規模なデータ (構造体および > 複合型 > 1 キロバイト) では CORBA ほど効率的ではありません。
パフォーマンスとは関係のないもう 1 つの奇妙な制限は、Thrift が構造体としていくつかの値のみを返すように制限されていることです。ただし、これはパフォーマンスと同様に、おそらく改善される可能性があります。
Thrift IDL が CORBA IDL とよく一致するのは興味深いことです。私は Thrift を使ったことがありません。特にメッセージが小さい場合は面白そうです。また、設計上の目標の 1 つは、インストールの煩わしさを軽減することでした。これらは Thrift のもう 1 つの利点です。とは言うものの、CORBA には評判が悪く、たとえばomniORBのような優れた実装が数多くあります。これには、Python 用のバインディングがあり、簡単にインストールして使用できます。
編集済み: Thrift と CORBA のリンクは無効になりましたが、CERN から別の有用な論文を見つけました。彼らは CORBA システムの代替品を評価し、Thrift を評価しながら、最終的に ZeroMQ を採用しました。Thrift は、パフォーマンス テストで 9000 メッセージ/秒と 8000 (ZeroMQ) および 7000+ RDA (CORBA ベース) で最速のパフォーマンスを発揮しましたが、特に次の問題があるため、Thrift をそれ以上テストしないことを選択しました。
実装にバグがあり、まだ未熟な製品です