2

OpenEJB4.0.0で使用できるトランスポートはいくつかあります。

  1. ejbd
  2. ejbds
  3. httpejbd

ネットワーク上でどちらが軽いですか？

どちらが速いですか？

その時のどれかを選ぶことの賛否両論はありますか？

OpenEJB4.0.0コンテナ上のリモートEJBと通信する約450のクライアントとしてのアプリケーション。すべてローカルLAN内にあります（ただし、ある程度の冗長性を備えたカスケードスイッチを使用しています）。

アップデート：

この質問は、タイムアウトに関する別の質問とは関係ありません。識別できるタイムアウトやアプリケーションの問題はありません。クライアントの数が限られている場合、アプリケーションは非常にうまく機能しますが、数百で試してみると、ネットワークエラーのように見えます。サーバーログに「IoExpcetion不明なバイトが受信されました」と繰り返し表示されます。CORBA ORBにはブロードキャストの問題があると報告されているため、IIOPよりもRMIのような問題である可能性があります。現在の設定と比較するために、他のプロトコルオプションを試してみます。

更新（2012年10月8日）：

現在、LAN内に450以上のクライアントを使用して、何百ものテストを実行しています。すべての答えにぴったりのサイズはありません。クライアントが非常に少ない場合は、EJBDの方が高速です。数百のクライアントがある場合、EJBDは機能しなくなります（スイッチが飽和状態になるようです）。何百ものクライアントがある場合でも、httpejbdは機能します（各リモート呼び出しが短時間のhttpリクエストを作成するという事実に関連しているようです）。

4

2 に答える 2

3

Jetty を使用した httpejbd は、より多くのクライアント (数千) にサービスを提供できますが、ejbd は数十から数百の範囲で大幅に高速です。

このメールには、純粋にパフォーマンスの観点から、両方に関する良い情報が含まれています。

表示されているタイムアウトは、クライアント/サーバーのパフォーマンスとは関係がないことをもう一度述べます。より高速なクライアント/サーバー層は、実際にはサーバーの不測の事態を増加させ、サーバー側のロックの問題をより明確にします。

私がお勧めするのは、タイムアウトの問題を引き起こしているのはプロトコル層であるという考えを払拭することです。クライアントがリモートであるという事実ではなく、クライアントの数である可能性が高いです。@Remoteから参照することにより、サーバーと同じ VM で Beanを実行することができますLocalInitialContextFactory。これが完了すると、リモート EJB セマンティクスに準拠したクライアント参照を取得できますが、ネットワーク プラミングは必要ありません。

このクライアントに 450 のスレッドを生成させ、各スレッドをループ内の連続した要求でサーバーにヒットさせ、通常のクライアントが行うような作業を行います。おそらく 450 スレッド (つまり 450 クライアント) よりはるかに少ないスレッドでタイムアウトに達する可能性があることがわかります。

これは、呼び出すことができるすべての方法のパフォーマンス分析です。これは、同じマシン上の同じオブジェクトです。

ポジョ

@Local

@Remote経由LocalInitialContextFactory、サーバー側

@Remote経由RemoteInitialContextFactory、クライアント側 (ejbd)

したがって、ネットワーク層が速度を低下させ、アクセス タイムアウトを引き起こしていることが直感的にわかっている場合は、小規模なパフォーマンス テストを作成してその仮定を検証し、LocalInitialContextFactoryと の両方で実行しRemoteInitialContextFactoryます。はLocalInitialContextFactory、任意のリモーティング レイヤーから期待できる理論上の最大パフォーマンスを示します。

問題が解消された場合は、その通りであり、ネットワーク層の調整に進むことができます。問題が解決しない場合、または問題が悪化する場合は、問題がネットワーク層ではないことがわかり、進行するためにフォーカスを変更する必要があります。

于 2012-08-10T22:20:58.017 に答える
0

私はこれらのプロトコルのいずれも使用していませんが、インターネット上でこれら 3 つのパフォーマンスの比較が見られないため、一般的なビューから始めることができると思います。基本的なネイティブおよび低レベルの実装は、ほとんどの場合、高レベルのプロトコルよりも高速であると私は信じています。このシナリオでは、SSL ハンドシェークのオーバーヘッドがあるため、ejbds は ejbd よりもパフォーマンスが低くなります。また、ejbds は httpejbd よりもパフォーマンスが低いと思います。

于 2012-08-09T17:16:09.483 に答える