2

クライアントサーバーアーキテクチャに基づいて構築された製品があります。使用されているテクノロジースタックに関する詳細。

  • クライアント-JavaSwing
  • サーバー-RMI
  • Javaデータベース-Oracle

クライアントは世界のさまざまな場所にありますが、JavaサーバーとOracleデータベースはスウェーデンの同じマシンにあります。このため、多くのネットワーク遅延があります。離れた場所にいるクライアントのパフォーマンスはひどいです。このアプリケーションは、50MBを超えるサイズのファイルを処理するために使用されます。一般に、各操作には約1000を超えるネットワーク呼び出しが必要です。

あなたの経験に基づいて、この問題にどのように取り組み、パフォーマンスを向上させますか？

編集：いくつかの質問に答える

  1. ファイルには、処理およびデータベースへの更新が必要な実際のビジネスデータが含まれており、一部を送信することはできません。
  2. 一部のネットワーク呼び出しはバッチ処理できますが、コードの大幅なリファクタリングが必要になります。これは2001年に作成された非常に古いアプリケーションです。アプリケーションの設計は、サーバーがすべてのサービスを保持し、コード全体で再利用可能になり、ビジネスロジックがクライアント側で作成されるようになっています。したがって、このビジネスロジックはサーバーを何度も呼び出すため、天文学的な数字になります。

-Snehal

4

12 に答える 12

4

往復の回数を減らします

1回の操作で1000往復するのは、天文学的な数字です。あなたがそれらの数字を見るべきではありません。

50MBのファイルでもまだ問題があります。その場合、転送をより効率的にする方法を見つけるか（2つの類似したファイル間のデルタのみを転送しますか？）、ある種のキャッシュを使用する必要があります。

WANトラフィックがアプリを殺しているので、リファクタリングを行う必要があるようです。

于 2009-04-27T09:28:47.220 に答える
2

大きなファイルと大量のリクエストをネット経由で送信すると、多くの時間がかかります。限目。ギガビット イーサネットにアップグレードできたとしても、プロトコルでは、クライアントが 2 つの連続するネットワーク パケットの間に数ミリ秒アイドル状態になることを要求します (他のホストも通信する機会を得るため)。

しかし、クライアントが遠く離れている (おそらくインターネット経由で接続されている) ため、ギガビット イーサネットは実現できません。

そのため、ビジネス コードをサーバーの近くに移動することが唯一の方法です。最も簡単な解決策は、サーバーと同じ LAN 内の小さなボックスにクライアントをインストールし、VNC または同様のプロトコルを使用してそれらにリモート アクセスすることです。

次のレベルでは、クライアントをビジネス レイヤーとディスプレイ レイヤーに分けます。ビジネス層をサービスに変え、表示層をクライアントにインストールします。このようにして、データは (高速な) イントラネット上でのみプッシュされます。結果を表示する準備ができたら、クライアントは結果 (小さなデータ) のみを取得します。

于 2009-04-27T11:54:05.717 に答える
1

Steve Souders 著の「High Performance Web Sites: Essential Knowledge for Front-End Engineers」は、これに関する非常に優れた本です。ここを参照してください。

スティーブのウェブサイトはこちら.

于 2009-04-27T10:34:46.703 に答える
1

-まだそうでない場合はサーバーをステートレスにする

- Hessian などのより軽量なリモート プロトコルを検討する

-レイテンシーがおそらくボトルネックです。クライアントでキャッシュを使用し、より大きなデータのチャンクを読み取ることを検討してください。1,000 回の往復は大きな負荷です。

-クライアントをリファクタリングして、ローカルで動作し、バックグラウンドで同期できるようにすることを検討してください

-プロファイラーを使用して、アプリケーションが最も時間を費やしている場所を確認し、それを最適化します

于 2009-04-27T09:32:59.677 に答える
1

操作のさまざまな部分の相対的な時間消費を測定しましたか? 個々のプロセスにかかる時間を測定するまで、私は何も触れません。

レイテンシの問題が鍵だと思います。しかし、解決策を検討する前に、まずこれを測定して判断します。

于 2009-04-27T09:37:25.453 に答える
1

コードを大幅にリファクタリングするか、アプリ全体を書き直してください。マネージャーが時間がかかると言った場合は、進行状況バーを追加して、ユーザーがより速く進むと思うようにします。

于 2009-04-27T19:56:05.090 に答える
1

おそらく最善の方法は、インフラストラクチャがどのように機能するかをよりよく理解することです。

  1. ファイルが非常に大きいのはなぜですか？
  2. ファイル全体を送信する必要がありますか、それとも処理に必要な部分だけを送信するだけで済みますか
  3. これらのネットワーク コールとは何ですか? それらはすべて必要ですか？その場合、呼び出しを 1 つの呼び出しにバッチ処理できますか?
于 2009-04-27T09:41:18.377 に答える
1

確かではありませんが、検証/処理してデータベースに保存したい50 MBのファイルにいくつかのデータがあるようです。それが正しいか？

クライアントが単にファイルをサーバーに渡し、サーバーが検証/処理タスクを実行してデータベースに保存できるのはなぜですか? これにより、ファイル データをサーバーに渡す以外のネットワーク呼び出しはありません。

他の可能性は、1 回の呼び出しで複数の操作をクラブできる場合、つまりセッション ファサード パターンです。

于 2009-04-27T10:26:26.303 に答える
0

プロトコルを変更できない場合は、少なくともペイロードを変更します。

1) これは閉鎖的なシステムのように聞こえます。はいの場合、一般化されたシリアライズ可能なプロトコルを使用する必要はありません。Externalizable に切り替えて、電信送金用にオブジェクトの状態をキャプチャするために必要な最小限のデータを書き込みます。

2) サーバーからクライアントに送信されるデータを圧縮します。(1) のオブジェクトの状態を超えて、ネット上を移動するデータ ブロブ (「ファイル」) も減らす必要があります。

それを超えて (これは明らかにシステムに依存します)、フォワード キャッシング ノードを検討する必要があります。多くのアプリケーションでは、ドメイン エンティティ アクセスのパターンがあります。悪用できる地理的アクセス パターンがある場合は、リモート サーバーのクライアントである新しいプロキシ ノードを簡単に作成し、近くの (rmi) クライアントに対して (rmi) サーバーとして機能できるはずです。

于 2009-05-10T11:48:31.470 に答える
0

各操作に 1000 件のリクエストが必要です。これにより、サーバーが強制終了されます。これは通常、ハードウェアを追加したり帯域幅を追加したりしても解決できない問題です。これは設計上の問題です。とにかく、サーバーのステータス（メモリ消費、CPUなど）を確認するためにプロファイラーをインストールします。ラムダ プローブを見てみましょう ( http://www.lambdaprobe.org )

于 2009-04-27T09:39:44.573 に答える