2

私の要件は、Asp.Net Web アプリケーションで 2 秒未満で 100 個のサムネイルを読み込むことです。各画像の実際のサイズは約 800 KB です。そのため、Web ハンドラー メソッドを使用してその場で画像のサイズを変更しました (ここでは画像サイズを 8KB に縮小しました)。ここでは、96 のリクエストがサーバーに送信され、サムネイルが 4 秒未満で読み込まれることがわかりました。90% の確率でブロックで負けていることがわかりましたFirebug net タブで調べます。それで、96 リクエストから 1 つのリクエストに移行しました。したがって、Web ハンドラーは単一の要求を受け入れ、96 個のサムネイル画像を作成し、96 個のサムネイルを結合して大きな単一の画像にし、この単一の画像を出力ストリームに書き込みます。この場合、単一の画像の読み込みに約 6 秒かかることがわかりました。次に、Web ハンドラーでサムネイルを作成するために .Net スレッド プール メカニズムを使用しました。これにより、読み込み時間が 2.6 秒に短縮されました。サーバーの処理に実際にかかる時間は 1 秒以下であることがわかりました。残りの 1.6 秒が失われています。私の質問は以下のとおりです

  1. 処理時間が失われているのはどこですか。サーバー側かクライアント側か? サーバー側の場合、ボトルネックはどこですか? リクエストの処理時間とページの読み込み時間を特定するにはどうすればよいですか?

  2. 画像のサイズ変更を行うには、Web ハンドラーの方が適していますか?

  3. 代替ソリューションはありますか?

私のシステム構成は

プロセッサー - Intel Core - i7、RAM: - 4 GB

ウェブサーバー: IIS 7

OS：Windows7

私を助けてください

4

1 に答える 1

0

> 処理時間が失われているのはどこですか。サーバー側かクライアント側か?

たぶんその中間です... 1.6秒はデータを転送するのに適しています:

8KB per image * 100 images ~= 1MB of data
1 M bytes = 8 M bits
8 M bits / 1.6 secs = 5 Mbps transfer rate
... sounds reasonable to within an order of magnitude

これにより、100 個の個別のリクエストのオーバーヘッドが削減されるため、1 つの大きなイメージのアプローチがおそらく優れています。ただし、ASP.NET プロセスでバックグラウンド スレッドを使用することに注意してください。

転送時間は制限要因の 1 つです。サーバーをすぐに応答させることができたとしても、データがクライアントに返されるまで待つ必要があります。

もう 1 つの制限要因は、クライアント ブラウザが画像をレンダリングできる速度です。

基本的に、あなたの要件は実用的な ATM の境界を押し広げています。

于 2012-04-30T19:58:52.560 に答える