在C＃/ WCF應用程序中使用原因不明的CPU

我有一個麻煩的問題，我不知所措。簡而言之，我的Web場中的Web服務器使用CPU的難度令人難以置信。在C＃/ WCF應用程序中使用原因不明的CPU

我有大量的用戶打兩個前端Web服務器。 99％的頁面加載是Ajax請求，並提供一個簡單的JSON序列化對象，Web服務器使用WCF從後端檢索。在典型的情況下（大概99％的請求），所有的ASPX頁面都在做一個WCF調用來獲取這些數據，並將其序列化爲JSON字符串並返回。

該對象非常小 - 一個GUID，一對短字符串，幾個整數。

非典型情況是初始頁面加載，它執行相同的操作（WCF請求），但使用asp：literals將響應注入頁面的不同部分。

所有三臺機器（2個Web服務器，一個後端）具有相同的硬件規格。我期望後端在這種情況下完成大部分工作，因爲它管理所有數據，執行查找等。但是：後端的負載是，比前端的負載低。後端是一個很好的，級別10-20％的CPU負載。前端平均運行時間爲30％，但它們全都在地圖上，有時會在10秒內達到100％的峯值，並且需要600毫秒才能爲這些非常簡單的頁面提供服務。

當我在profiler（ANTS）中運行前端時，它將WCF通信標記爲佔用80％的CPU時間。這是.NET生成的WCF代理的整個調用。

WCF設置：服務完全平行。我已將實例設置爲「單個」，併發設置爲「多個」。我將服務上的maxConnections和listenBacklog打開到256.在緊張的情況下（500個請求/秒），我看到兩個前端服務器和服務之間打開了大約75個連接，所以它沒有打到牆上。我的安全性設置爲「無」。帶寬使用率約爲潛在的1/20（100Mb/s網絡爲4Mb/s）。

在客戶端（Web服務器）上，我爲該服務創建了一個靜態ChannelFactory。代碼來調用服務的樣子：

service = MyChannelFactory.CreateChannel(); 
try { 
    service.Call(); 
    service.Close(); 
} catch { 
    service.Abort(); 
}

（簡化，但你得到的基本圖片）

我不明白的是，其中在前端所有這些負載是從哪裏來的。奇怪的是，它從來不在30％-90％的範圍內。它處於恐慌模式（100％）或正常（30％或更少）。但是，考慮到後端的負載，我預計這兩臺機器都會達到10％或更低。內存使用，句柄等等，都顯得合理。

要添加一個皺紋：當我記錄在後端服務這些調用需要多長時間時，我得到的時間始終小於15ms（可能每分鐘有一個或兩個尖峯到30ms）。在前端，這些調用可能需要1秒才能返回。我想這可能是因爲CPU的問題，但它似乎對我來說。

所以......有沒有人有什麼想法在哪裏看這種事情？我正在探索一些事情。

澄清：WCF服務託管在Windows服務中，並且正在使用netTcp綁定。另外，我將客戶端上的maxConnections設置爲128，FWIW。

來源

2010-01-26 Moxen

@Moxen：找出問題所在？ – LBushkin 2010-04-23 19:38:57

我們也有一個NetTCP WCF服務託管在Windows服務中，這種行爲在移到.NET後突然顯示出來4 您有任何更新嗎？我們正在考慮轉向基於IIS/ASP.NET，但我不相信它會解決這個問題。 – Jaans 2013-02-13 03:45:33

很難說可能會發生什麼，但一個瘋狂的猜測是某件事正在引發一個爭用點和它的旋轉（而不是等待）。

有沒有機會增加前端服務器中後端服務器的HTTP連接數量？你可以做到through the config file。我在WCF客戶端看到的一個常見問題是，限制保留爲默認值2，這嚴重限制了客戶端代理級別的併發性。

來源

2010-01-26 01:27:07 tomasr

對 - 我有這樣的印象：它正在忙着等待什麼，但我無法弄清楚什麼。看起來，如果需要的話，它仍然有空間建立更多的服務連接。稍微詳細一點 - WCF服務作爲Windows服務託管，而不是IIS的一部分。我有maxConnections設置爲128綁定（順便說一句，是netTcp）。 – Moxen 2010-01-26 02:05:05

這兩件事情都沒有關係。我所描述的問題與服務器無關（我同意你在那裏做了正確的更改），但是在*客戶端*上。默認情況下（這是HTTP規範建議的），HttpWebRequest（WCF在內部使用）一次將連接到單個遠程服務器的連接限制爲2個併發HTTP連接。這意味着無論您的服務器設置如何，您的客戶端可能會遇到爭用。 – tomasr 2010-01-26 03:13:57

HttpWebRequest連接限制是否會影響netTcp綁定？我不認爲這是發生的，因爲我確實看到兩臺機器之間的數十個開放連接。在壓力測試中，連接從零開始並最終工作。而套接字（根據netstat）絕對處於'ESTABLISHED'狀態。 – Moxen 2010-01-26 15:52:14

您是否考慮並測試了外部因素的可能性？

過程回收？
是否啓用動態壓縮？

來源

2010-01-26 01:27:18 keithwarren7

我想到的第一件事就是過程回收。 – Cheeso 2010-01-26 01:44:29

這些機器除了Web服務器上的ASP.NET和後端上的一個WCF Windows服務之外，沒有其他任何其他服務器在其上運行。「ASP.NET v2.0.50727 /應用程序重新啓動」計數器不顯示任何重新啓動正在進行。並且應用程序池未設置爲在X請求後自動重新啓動。 – Moxen 2010-01-26 02:12:34

在C＃/ WCF應用程序中使用原因不明的CPU

回答

相關問題