我試圖研究另一個開發者報告的問題。他聲稱,當我們創建的Silverlight應用程序使用併發調用很難打開一個WCF Web服務時,這些調用開始堆疊在服務器上。他的說法是我們正在使用會話,因爲我們使用的身份驗證方法(使用表單和SQL Server的asp.net成員資格)。所以,我創建了一個非常簡單的測試應用程序Silverlight併發WCF
該應用程序允許我指定併發調用Web服務我想要的號碼,然後指示優秀的呼叫的當前數量,並在幾秒鐘內,平均響應時間。
Web服務本身的簡單使線程休眠的第二
public void DoWork()
{
Thread.Sleep(1000);
}
所以,我以爲會發生的事情是,如果我的同事是正確的,那麼電話將在服務器上疊加起來那麼平均響應如果有兩個併發呼叫,則會是2秒。然而,似乎發生的事情是,時間保持在一秒以上,直到我達到七個併發請求,然後開始相對可預測地增加。
運行第二個客戶端(在初始IE窗口旁邊的Chrome窗口中)似乎不會影響性能(存在初始打嗝)。如果你並排運行兩個IE瀏覽器或兩個Chrome瀏覽器,情況並非如此,那麼這兩者似乎會相互影響,表明他們正在共享連接。
這似乎也是提琴手干擾。我用7個併發呼叫運行沒有提琴手的應用程序,平均每次通話約1.15秒。然後我開始擺弄小提琴手,時間又回到了一秒多,這就好像小提琴手允許額外的通話一樣。
所以我的問題。這裏發生了什麼?節流(在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顯然是爲每個會話創建和實例化的。然而,我們正在使用基本的HttpBinding作爲端點,我已經看到這不支持會話,所以我對此有點困惑。
爲了完整這裏是在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>
我一直在做更多的研究,服務行爲屬性應該阻止併發呼叫從同一個會話到達服務。然而,它似乎確實沒有維護會話,並且每個呼叫正在獲得新的會話。這種類型與我讀到的有關basichttpbinding不支持會話的內容一致。我懷疑需要更多的工作。 – naskew