1 つの IIS アプリケーションで多数の .NET Web サービスを実行しています。これらの Web サービスは、別の IIS アプリケーション (フロントエンド) によって使用されます。最初の呼び出しはかなり遅く、約 5 ～ 10 秒です。その後はミリ秒です。最初の呼び出しは、パフォーマンスの問題と見なされます。
これらすべての Web サービスを呼び出すアプリケーションを試してみましたが、明らかに何も解決しません。したがって、問題はデフォルトのアプリケーション リサイクルではありません。サービスを数回初期化し、1 つのインスタンスを作成するのにかかる時間を測定するだけのアプリケーションを作成しました。このアプリケーションを実行する前に、Web サービス アプリケーションが開始/リサイクルされていることを確認してから、アプリケーションを実行します。最初の初期化には 2 ～ 4 秒かかり、その他はすべてミリ秒です。
もう 1 つの考えは、フロントエンド アプリケーションですべての Web サービスを開始するページを作成し、ユーザーが入る前にこのページを呼び出すことです。
クライアントが初めて Web サービスを呼び出すときに発生する遅延は、デフォルトで Web サービスの XmlSerializers dll をコンパイルする必要があるという事実によって発生します。これにより、最初の呼び出しに 2 ～ 4 秒かかります。もちろん、これは Web サービス アプリケーションが既に実行されている場合に当てはまります。そうでない場合は、リサイクルが必要になります。その場合、他の回答が役立ちます。
最初の呼び出しを高速化するために、コンパイル時に XmlSerializers dll を作成できます。これを行うには、プロジェクト ビルドの [シリアライゼーション アセンブリの生成] をオンに設定します。これにより、Web サービス情報を含む MyApplication.XmlSerializers.dll が生成されます。これで、最初の呼び出しが 300 ミリ秒に短縮されました。これは、おそらく dll の読み込みです。その後の呼び出しはすべて 0 ミリ秒かかります。
Visual Studio でプロジェクトを右クリックし、[プロパティ] を選択します。「ビルド」タブに移動します。「出力」セクションに「シリアル化アセンブリの生成」オプションがあります。値を「オン」に変更すると、コンパイル時にシリアル化アセンブリが生成されます。
Web サービスを初めて呼び出すとき、または長い遅延の後で初めて Web サービスを起動する必要があります。これは、遅延が発生している場所です。その後、それはすでに開始されており、呼び出しに非常に迅速に応答します. これは、標準の Web サービスの動作です。
IIS を構成して keepalive = true にすることができます。これにより、パフォーマンスが向上する可能性があります。
要求に応じて詳細情報。
シリアル化アセンブリが実行時に作成されている可能性があります。プロジェクトのプロパティ ウィンドウの [ビルド] ペインの下部にあるドロップダウンを使用して、シリアル化アセンブリの設定を変更できます。
アプリケーションの開始時に多くの操作を実行するように Web サービスを作成した可能性があります。これは、サービスのメソッドが初めて呼び出されたときに発生します。
操作が非常に遅い可能性がありますが、応答をキャッシュしているため、後続の呼び出しが高速になります。
私は最近、ASMX ファイルでクラス名のみを参照していることを発見しました。ASMX ファイルごとに異なるアセンブリでサービスの実装を取得しました。これにより、.NET フレームワークは bin フォルダー全体をスキャンして、実装を含むアセンブリを探します。Web サービス アプリケーションが大きくなるにつれて、これにはより多くの時間がかかります。これは、ASMX 定義にクラス名を含めるだけでなく、アセンブリ名も含めることで解決できます。
ASMX は次のようになります。
<%@ WebService Language=”C#” CodeBehind=”MyService.cs” Class=”MyWebservice” %>
実装を含むアセンブリを含めるように変更すると、次のようになります。これにより、Web サービス アプリケーションの初期負荷を約 10% 節約できました。
<%@ WebService Language=”C#” CodeBehind=”MyService.cs” Class=”MyWebservice, MyWebservice.Implementation.Assembly” %>
ASP.NET アプリは、最初の要求で bin\ ディレクトリをコンパイルしてメモリに読み込むため、これは一般的なことです。
最初に行うこと:
bin ディレクトリにある不要な dll をすべて削除します。(人々が nunit.dll を出荷しているのを見たことがあります)
IIS が不要になるように、ASP.NET アプリをプリコンパイルします。「VS 2008 Web Deployment プロジェクトのサポートがリリースされました 」を参照してください。
コンパイルと .net DLL のロードの負荷があると想定しているため、これが「初めて」の WS の遅いスピンアップを解決するかどうかはわかりませんが、アプリケーション プールを確保することで、将来のコールド スタートをほぼ排除できます。 WS は正しく構成されています。
デフォルトでは、IIS6 は数分後にアイドル状態で「リスポーン」するか、毎回 WS を効果的に再起動する「リサイクル」イベントを行います。サービスが安定していることに満足している場合、これらは必要ありません。
WS に専用のアプリケーション プールがある (不適切なプールを共有していない) ことを確認することも強くお勧めします。
数時間の非常識なテストの後、同じ IP クラスの 2 つのホストから、Web サービスの最初の実行時間を最小限に抑えることができました (300 ミリ秒未満)...
同じプロセスからの後続の呼び出しが非常に高速であるよりも、最初の Web サービス呼び出しで最初に 2 ～ 3 秒の初期遅延が発生しました。
私の場合の遅延を理解するための鍵は、クライアントが WEB PROXY を処理する方法でした!!
これは、app.config ファイルの新しいバインディングです。
<basicHttpBinding>
<binding name="CreateContextSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="01:00:00" sendTimeout="01:00:00" allowCookies="false"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="16777216" maxBufferPoolSize="524288" maxReceivedMessageSize="16777216"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="false">
<readerQuotas maxDepth="32" maxStringContentLength="1048576" maxArrayLength="16384"
maxBytesPerRead="65536" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
インターネットに透過的に接続するために、トランスポート チャネルは初期化時にプロキシ構成を検出する必要があるため、最初の webcall の実行はかなり遅くなると思います。これは通常、イントラネット環境では必要ありません。したがって、これらのバインド設定を変更して、デフォルト プロキシ (エクスプローラー設定から自動的に検出されます) の使用を回避しました。
bypassProxyOnLocal="false"
useDefaultWebProxy="false"
最初の通話の接続時間が大幅に短縮されました。お役に立てれば。