IIS 8.5シングルワーカープロセス対ウェブガーデンパフォーマンス

Question

私は単純なASP.NETアプリケーションを持っていて、画像をImageResizerでサイズ変更するだけで何もしません。テスト目的のために、私はディスクキャッシングを無効にしたので、イメージはすべてのリクエストでサイズ変更されました。

私はJMeterのとアプリのパフォーマンスをテストするとき、私は以下の平均応答時間を取得：

• 単一のワーカープロセス、1つの同時クライアント：〜200msの
• 単一のワーカープロセス、10の同時クライアント：〜1200msを
• 4ワーカープロセス、10の同時クライアント：〜300msの

私は、単一のワーカープロセスと10の同時クライアントを実行すると、応答時間がDRを増大させ、見ることができるように利用可能なハードウェアリソースにもかかわらず、パフォーマンステスト中のCPU使用率は〜30％、メモリ使用量は約150MBです。

としてはhere、

Webガーデンが1つの理由のために設計された議論 - CPU-バインドされていないアプリケーション を提供していますが、長時間実行を実行中のすべてのスレッドが使用可能に使い切るスケールではなく能力 を要求ワーカープロセス

これは私のケースではありません。

私はなぜこのような結果を得るのか分かりません。私が期待しているのは、単一のワーカープロセスであっても、リソース制限に達するまで、許容可能な応答時間を提供するということです。また、10人の同時クライアントは、重い負荷ではありません。誰かが私に説明することができます、どこが間違っていますか？

マイ設定：

• のWindows Server 2012 R2
• は（MaxWorkerThreadsを除く）すべてのデフォルト設定
• クアッドコアi3は3.4GHz以上のCPU
• 16ギガバイトのRAM

と8.5のIIS

私のアプリケーションは空です。ImageResizerを持つASP.NET MVCアプリケーション。this instruction（オプション3 - マニュアルI nstallation）とDiskCacheプラグインをWeb.configで無効にした場合

Answer 1

@Benのコメントのおかげで答えが見つかりました。

ImageResizerは、内部にロックを含むGDI +（it's siteに記載）に基づいています（詳細についてはthisおよびthisの投稿を参照してください）。これが、単一プロセスでゆっくりと動作する理由です。

問題の原因を見つけた後、私はthis solutionを試しました。おそらく、WPFアセンブリをASP.NETアプリケーションから参照することはベストな方法ではありませんが、テスト目的では問題ありません。

今、私が問題になっているのと同じ性能試験を行うとき、私は次のような結果を得る：

• 単一のワーカープロセス、1つの同時クライアント：〜90msの
• 単一のワーカープロセスを、10の同時クライアント：〜120msのを
• 単一のワーカープロセス、40の同時クライアント：〜190ms
• 単一のワーカープロセス、60の同時クライアント：〜400msの
• 単一のワーカープロセス、80の同時クライアント：〜630ms

ご覧のとおり、アプリケーションははるかに高速に動作します。また、当初期待していたように、負荷の高いCPUリソースをほとんどすべて利用しています。

だから、あなたはあなたのASP.NETアプリケーションで画像を処理する場合：

• あなたがGDI +を使用する必要があれば、あなたが
• 、applicaionでMaxWorkerProcessesを増やすことができれば、GDIは+ベースのソリューションを使用しないでくださいプールの設定