服務請求在客戶端在同一臺服務器上進行服務時排隊

我有這個奇怪的問題。我在服務器上有3個WCF服務。經理服務是外部請求的主要入口點。另一項服務是應用程序的邏輯。第三項服務是數據庫連接服務，這兩項服務都涉及並且正在完成大部分工作（數據庫都是這樣）。服務請求在客戶端在同一臺服務器上進行服務時排隊

當我運行請求管理器的負載測試和運行性能測試，我得到了90級不同的線程同時運行，第二個服務了約50和數據庫連接只有約12

我覺得這是應用程序中的主要性能問題。當我分析這兩種服務時，我發現他們確實在等待數據庫服務的響應。

我試着直接對DB服務進行測試。我運行了80個線程，並在打開通道之後並在發送請求之前使用ManualEventHandler停止它們。那麼當所有的準備工作完成時，我已經設置了處理程序，並在數據庫連接服務中運行了大約25個線程

所以它能夠處理多於12個線程。

有什麼想法是怎麼回事？

爲什麼請求排隊？

一些額外的信息：

綁定是basicHttpBinding的，但我試着用同樣的結果淨管IPC。我已經設置上下文模式和併發性爲每次調用或每個會話倍數相同的結果。

此外，服務是自我託管。這是體系結構的原因就是爲了讓多個其他服務或應用程序直接向這些服務發送請求。在這個特定的事件中，我按照描述測試它，在其他事件中，流程可能會有所不同。

來源

2012-06-28 Mithir

您是否對'ConcurrencyMode'設置進行了任何設置？請參閱：http://msdn.microsoft.com/en-us/library/system.servicemodel.concurrencymode.aspx。它對服務間通話有影響。 –

爲什麼這個設計，如果你不介意我問？對我來說似乎是在尋求麻煩。 –

@thecoon爲什麼會這樣麻煩？你能詳細說明嗎？ – Mithir

這意味着這些請求正在排隊中途。如果所有的服務託管在IIS上，您可以使用ASP.NET性能計數器查看每個服務級別上的掛起請求數（根據我的知識，WCF不提供這樣的性能計數器）。由於@ coon認爲這是錯誤的架構方法。每個服務調用可以被認爲是昂貴的，與同時在不同層上執行相同服務的業務邏輯和數據訪問操作相比。說實話，我沒有看到使用這種方法的理由。

來源

2012-06-28 14:17:39

我知道請求已排隊，我問他們爲什麼排隊。我知道它可能看起來錯了，但是你會如何建議不同的做法，同時還允許其他客戶端直接向db連接服務發送請求？ – Mithir

您是否配置了併發模式和限制？如果所有服務都是WCF（並且我假設它們是），並且您可以訪問所有服務（並且我假設您這樣做），則只能將這些合同從DB服務和業務服務移動到一個服務中。在這種情況下，您將有一個業務服務的入口點，它將直接訪問DAL（而不是通過調用單獨的服務）。另外，如果有客戶必須僅訪問DAL，那麼不存在問題，因爲這些DAL方法使用不同的合同在同一服務中公開。您在服務之間使用什麼樣的綁定？ –

安全性如何？ –

服務請求在客戶端在同一臺服務器上進行服務時排隊

回答

相關問題