ASP.net 2.0 app .net2.0フレームワークIIS7
「ワーカープロセス」オプションの下に「リクエスト」の大きなキューが表示されます。記録された状態は、何よりも認証要求と実行要求処理のように見えます。
C:\ Windows\Microsoft.NET\Framework64\v2.0.50727(32ビットパスと64ビットパス)のaspnet.configを次のように修正しました。
maxConcurrentRequestsPerCPU="50000"
maxConcurrentThreadsPerCPU="0"
requestQueueLimit="50000"
C:\ Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG(32ビットおよび64ビットパス)のmachine.configを次のように修正しました。
autoConfig="true"
maxIoThreads="100"
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"
minFreeThreads="176"
minLocalRequestFreeThreads="152"
それでも問題が発生します。
この問題は、ワーカープロセスキュー内の多数のプロセスとして現れます。
この問題が発生した場合、Webサイトへの現在の接続数は500を表示します。この問題が発生することなく、500を超える同時接続を見たことがないと思います。
Webアプリケーションは、要求ブロックとして遅くなります。
アプリプールの更新は、2つのプール間で負荷が分散されるため、しばらくの間(予想どおり)解決されます。
問題のアプリケーションプールFIXEDREQUESTは、50000に更新するように設定されています。
助けてくれてありがとう。スコット
簡単に編集して、うーん、私の開発者は、プロジェクトが.net3.5フレームワークで構築されたと言っています。見つめている
C:\ Windows\Microsoft.NET\Framework64\v3.5
aSPNET.CONFIGまたはMACHINE.CONFIGがないようです.... 3.5に相当するものはありますか?
少し検索した後、3.5は3.5にない2.0フレームワークファイルを使用します。
では、元の質問に戻りましょう。私のボトルネックはどこにありますか?
IISの最適化とパフォーマンスチューニング は非常に幅広いトピックであり、ボトルネックはいくつかの場所にある可能性があります。
まず、 パフォーマンスモニター を使用して、ボトルネックをより適切に判断できます。
そこで見つけたものに基づいて、次のIISパフォーマンスチューニングオプションを試すことに進むことができます。
デフォルトでは、web.configファイルの接続文字列の最大プールサイズは100なので、"Max Pool Size=200; Min Pool Size=10; Connect Timeout=45;"
などのより大きな値を指定してみてください。
例:
<add name="SiteSqlServer" connectionString="Server=mydomain.com;Initial Catalog=myDB;User ID=DB;Password=myDB;Max Pool Size=100;Min Pool Size=10;Connect Timeout=45;" providerName="System.Data.SqlClient" />
場所:C:\ Windows\Microsoft.NET\Framework\v2.0.50727およびC:\ Windows\Microsoft.NET\Framework64\v2.0.50727
例:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000" <!-- Default is 12 -->
maxConcurrentThreadsPerCPU="0" <!-- Default is 0 -->
requestQueueLimit="5000" <!-- Default is 5000 -->/>
</system.web>
場所:C:\ Windows\Microsoft.NET\Framework\v2.0.50727\CONFIGおよびC:\ Windows\Microsoft.NET\Framework64\v2 .0.50727\CONFIG
例:
<processModel
enable="true"
requestQueueLimit="5000" <!-- Adjust if necessary. Default 5000 -->
restartQueueLimit="10" <!-- Adjust if necessary. Default 10 -->
memoryLimit="60" <!-- Adjust if necessary. Lower for memory leaks. -->
maxWorkerThreads="100" <!-- Default 20 -->
maxIoThreads="100" <!-- Default 20 -->
minWorkerThreads="40" <!-- Default 1 -->
minIoThreads="30" <!-- Default 1 -->
/>
例:
<system.net>
<connectionManagement>
<add address="*" maxconnection="100" <!-- Default is 2 --> />
</connectionManagement>
</system.net>
サーバーの変更で少し前進できるかもしれませんが、この場合、本当の問題はコードにあるようです。何かが原因でコードがタイムラインで完了できず、リクエストがビルドされています。
ワーカープロセスキューを使用して、どのページが最も長く構築されているかを確認します。それは単一のページ、またはページのパターンである可能性があり、そうでない場合は、通常、他のすべてを保持している上部に1つのページがあります。
Debug Diagは、ロックページを分離するためのより高度なトラブルシューティングに最適なツールです。
あなたはフレームワークのバージョンについて正しいです。 .NET 3.0および3.5は、2.0の拡張機能です。対応するaspnet_isapi.dllおよびその他のコアファイルを備えたまったく新しいフレームワークバージョンが登場するのは4.0までです。