Java アプリケーションの場合、パフォーマンスの点で Tibco rv と Hessian を比較したいと考えています。
私が始めるための指針は高く評価されています。ありがとう。
Java アプリケーションの場合、パフォーマンスの点で Tibco rv と Hessian を比較したいと考えています。
私が始めるための指針は高く評価されています。ありがとう。
「パフォーマンス」が何を意味するかによります。
私は Tibco で多くの経験を積んできましたが、Hessian は経験していないので、RV 側についてしかコメントできません。
RV は、ネットワークとサーバーのリソースを非常に効率的に (つまり、非常に効率的に) 使用します。TCP/IP ブロードキャストを多用して、n 個のクライアントに同じメッセージを送信しないようにします。さらに、メッセージはクライアントに直接送信されるのではなく、マシンにログオンしているすべてのクライアントにメッセージを転送するマシン上のエンド ポイントに送信されます。
さらに、コア製品は数年前のものであり、1995 年頃には非常に控えめなハードウェアと見なされていたもので動作するように設計されていました (シングル プロセッサ 200 mhz 256 MB メモリ SparcStation は、サーバー エンドでは一般的でした!) したがって、今日のハードウェアでは、膨大な量を処理できます。 「トップ」リストの一番下に座っている間のメッセージの数。
いくつかの欠点があります (たとえば、Webshpere MQ と比較して)。トランザクションのサポートは制限されており、MQ またはデータベースの標準に達していません。また、組み込みの保証付き配信や「デッド レター」処理はありませんが、アプリケーションでこれを回避するコーディングはかなり簡単です。
私が始める場所は次のとおりです。
最初に、メッセージング サービスの基礎となる構造を調べます。
TIBCO Rendezvousは、TCP/IP の上に直接構築されているように見え、幅広いクロスプラットフォームをサポートしています。
Hessian Messagingは、標準の RPC の上にあるコードのレイヤーのようです。これにより、おそらく保守がよりシンプルで簡単になりますが、RPC 実装に完全に依存していることも意味します。
別のアプローチは、それを使用している人の数と、それがどれだけよくテストされているかを比較することです.
最後に、TIBCO と Hessian がデモ バージョンを提供しているかどうかを確認して、独自の環境で実際にストレス テストを行い、独自の設定でのパフォーマンスの最良のアイデアを得ることをお勧めします。