6

複雑な計算を行う.NET関数があります。渡されるパラメーターに応じて、関数は次のようになります。

  • 実行には数分から数時間かかります
  • 計算中にシングルコアを100％使用します
  • 数百MBから数GBのメモリが必要です
  • 数MBから数GBのデータをディスクに書き込みます
  • OutOfMemoryExceptionを含む例外をスローする可能性があります

ディスクに書き込まれるデータの量は、関数のパラメーター化から正確に予測できます。関数のパラメーター化から他のリソース要件を予測する簡単な方法はありません。

この関数をWebサービス経由で公開する必要があります。このサービスは次のようにする必要があります。

  • 計算中に問題が発生した場合は、弾力性があり、適切に報告します
  • パフォーマンスを大幅に低下させることなく要求を処理するのに十分なリソースがあり、それ以外の場合は要求を適切に拒否するのに十分なリソースがある限り、同時要求を処理できます。

最初のリクエストで進行状況をポーリングできるステータスリソースを返すようにすることで、長期的な性質を処理するつもりです。計算が完了すると、このリソースは、クライアントがダウンロードできる出力データの場所を提供します（おそらくFTP経由で）。

他の要件をどのように処理するのが最善かについては、あまり明確ではありません。電卓のインスタンスを維持し、現在使用されているものを追跡する、ある種の「計算プール」を検討していますが、詳細はわかりません。

同様の状況の経験がある人は何か提案がありますか？ソリューションがWindowsボックスで実行できる限り、すべてのテクノロジオプションを検討できます。

4

2 に答える 2

4

アプリケーションを2つの部分に分割することをお勧めします。

  1. Webサービス自体。それは機能です：
    • クライアントから作業項目を取得します。
    • この作業を実際の作業を実行するバックエンドサービスに転送します。
    • 進捗状況と結果を報告します。
  2. バックエンドサービス。それは機能です：
    • Webサービスからリクエストを処理します。
    • 実際の計算を実行します。

この設計の理由は次のとおりです
。1）サーバー（IIS）がリソースを管理するため、ホストされたアプリケーション（ASP.NET）でワークロードを処理するのは比較的困難ですが、別のアプリではより直接制御できます。
2）2層設計はよりスケーラブルです。たとえば、後でバックエンドを別の物理マシン（または複数のマシン）に簡単に移動できます。

Webサービスはステートレスである必要があります。たとえば、リクエストが受け入れられた後、ユーザーはIDを取得し、このIDを使用してサービスの結果をポーリングします。

バックエンドサーバーは、おそらく、処理する要求のキューと、それらを処理する一連のワーカースレッドを維持する必要があります。ワーカーは、使用可能なリソースを監視し、マシンに過負荷がかからないように注意する必要があります（もちろん、考えられるすべてのエラー状態を適切に処理します）。

于 2010-11-12T10:26:10.650 に答える
2

Webサービスインターフェイスを提供することもできますが、Webサービスは通常、この種のプロセス用に設計されていません。実行したいのは、これを処理できるWindowsサービス（専用マシン上）に要求を転送することです。Windowsサービスはリサイクルされず、プロセスをより細かく制御できます。

計算プールについて：試してみることができるのは、計算キュー（たとえば、データベース内のテーブル）を作成することです。このようにして、計算を処理する専用マシン上に複数のWindowsサービスを配置できます。これにより、より簡単にスケーリングできます。

于 2010-11-12T09:53:52.967 に答える