別の開発者が報告した問題を調査しようとしています。彼は、私たちが作成した Silverlight アプリケーションが同時呼び出しで WCF Web サービスにハードヒットすると、サーバーで呼び出しがスタックし始めると主張しました。彼の主張は、私たちが使用している認証方法（フォームとSQLのasp.netメンバーシップを使用）のためにセッションを使用しているというものでした。だから私は本当に簡単なテストアプリケーションを作成しました
このアプリケーションでは、必要な Web サービスへの同時呼び出しの数を指定でき、現在の未処理の呼び出しの数と平均応答時間を秒単位で示します。
Web サービス自体は単純にスレッドを 1 秒間スリープさせます
public void DoWork()
{
Thread.Sleep(1000);
}
したがって、私の同僚が正しければ、呼び出しがサーバーに蓄積されるため、2 つの同時呼び出しがある場合、平均応答は 2 秒になると考えられます。ただし、発生しているように見えるのは、同時リクエストが 7 つになるまで、時間は 1 秒強のままであり、その後は比較的予測どおりに増加し始めるということです。
2 番目のクライアントを (最初の IE ウィンドウの横にある Chrome ウィンドウで) 実行しても、パフォーマンスに影響はないようです (最初の問題があります)。これは、2 つの IE または 2 つの Chrome を並べて実行する場合には当てはまりません。2 つが相互に影響を与え、接続を共有しているように見えます。
また、フィドラーが干渉していたようです。フィドラーを使用せずに 7 つの同時呼び出しでアプリケーションを実行したところ、呼び出しあたり平均約 1.15 秒でした。次に、フィドラーを開始すると、時間は 1 秒強に戻りました。フィドラーが余分な呼び出しを許可しているかのようでした。
だから私の質問。ここで何が起こっているのですか？スロットリング (6 つの同時要求) はどこで行われていますか (クライアントまたはサーバー)? フィドラーを実行するとリクエストが高速化されるのはなぜですか?
いくつかの追加情報。
Web サービス クラスにはいくつかの属性があります。
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single, InstanceContextMode = InstanceContextMode.PerSession)]
public class DoVeryLittle : IDoVeryLittle
{
public void DoWork()
{
}
}
AspNetCompatibilityRequirements は、asp.net パイプラインおよび認証との統合を可能にするためのものです。ServiceBehavour の ConcurrencyMode と InstanceContextMode は、セッションごとに作成してインスタンス化するようです。ただし、エンドポイントに basicHttpBinding を使用していますが、これはセッションをサポートしていないことがわかったので、これについて少し混乱しています。
完全を期すために、web.config のサービス関連のエントリを次に示します。
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceAuthorization principalPermissionMode="UseAspNetRoles" roleProviderName="AspNetSqlRoleProvider" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
</system.serviceModel>