Microsoft .NET Framework是最流行的應(yīng)用程序開發(fā)平臺和編程語言之一。C#和ASP.NET框架已被數(shù)百萬開發(fā)人員用于構(gòu)建Windows客戶端應(yīng)用程序，XML Web服務(wù)，分布式組件，客戶端-服務(wù)器應(yīng)用程序，數(shù)據(jù)庫應(yīng)用程序等。

隨著.NET應(yīng)用范圍越來越廣泛，對于大多數(shù)應(yīng)用程序所有者和開發(fā)人員來說，確保.NET應(yīng)用程序的優(yōu)良性能是最重要的需求。

.NET應(yīng)用程序運行緩慢的原因可能有很多。這些包括不正確的內(nèi)存大小調(diào)整，GC暫停，代碼級錯誤，異常的過多日志記錄，同步塊的高使用率，IIS服務(wù)器瓶頸等等。

在此博客中，我們將研究.NET應(yīng)用程序中的一些常見性能問題，并提供解決和解決這些問題的技巧。

1.未處理的異常與記錄過多異常日志

.NET異常不是一件壞事，只有錯誤的用法卻是壞事。這就是大多數(shù)開發(fā)人員所相信的，如果對異常進行了適當(dāng)?shù)奶幚恚磼伋?，捕獲和處理(并且不忽略)，則會帶來穩(wěn)定的性能。

然而，就像太多的廚師會寵壞了湯一般，太多未處理的異常會導(dǎo)致代碼效率低下并影響應(yīng)用程序性能[1]。

尤其是隱藏的異常更糟，這種隱藏異常就像雷區(qū)，一旦未能檢查這些異常，它們會影響網(wǎng)頁加載時間。

.NET的另一個問題是過多地記錄了異常。日志記錄可能是您的調(diào)試工具庫中的一個好工具，它可以識別在處理應(yīng)用程序時記錄的異常。

但是，當(dāng)設(shè)置日志記錄來捕獲應(yīng)用程序體系結(jié)構(gòu)每一層的異常時，最終可能會在Web，服務(wù)和數(shù)據(jù)層上記錄相同的異常。這可能會增加應(yīng)用程序代碼的負(fù)擔(dān)，并增加響應(yīng)時間。在生產(chǎn)環(huán)境中，只需要記錄致命事件和錯誤就需要小心。

記錄所有信息，包括參考消息，調(diào)試和警告，很容易使您的生產(chǎn)日志文件file臃腫，進而影響代碼處理。

有用的疑難解答提示：

• 確保您的C#代碼具有“嘗試最終捕獲”塊以處理異常。
• 利用C#6和更高版本中提供的異常過濾器，該過濾器允許為每個catch塊指定一個條件子句
• 檢查空值，并使用TryParse避免潛在的異常。
• 請注意第二次機會異常，因為它們表明出現(xiàn)了第一次機會異常，并且未正確處理它。
• 使用異常處理和日志記錄庫(例如企業(yè)庫，NLog，Serilog或log4net)將異常記錄到文件或數(shù)據(jù)庫中。
• 確保僅根據(jù)需要記錄異常，并且最終不會使日志文件膨脹。

2.過度使用線程同步和Lock

.NET Framework提供了許多線程同步選項，例如進程間互斥，讀取器/寫入器鎖等。

有時，.NET開發(fā)人員將以這樣的方式編寫代碼：在給定的條件下，只有一個線程可以得到服務(wù)。

時間以及其他要處理的并行線程將不得不在隊列中等待。例如，結(jié)帳應(yīng)用程序根據(jù)其業(yè)務(wù)邏輯應(yīng)一次處理一個請求。同步和鎖定有助于序列化傳入線程以執(zhí)行。通過創(chuàng)建同步的代碼塊并在特定對象上施加鎖定，需要傳入線程等待直到同步對象上的鎖可用為止。盡管此策略在某些情況下會有所幫助，但不應(yīng)過度使用。

有用的疑難解答提示：

• 使用同步編碼，僅在必要時使用鎖。在決定使用鎖之前，請先了解代碼執(zhí)行的需求。
• 最佳地調(diào)整鎖的持續(xù)時間范圍，以便延遲獲取并提前釋放它們，并且不會長時間等待其他線程。
• 為了減少并發(fā)問題，請考慮使用松散耦合。事件委托模型也可以用于最小化鎖爭用。
• 使用代碼分析工具[2]監(jiān)視.NET代碼，以識別線程鎖定是否導(dǎo)致應(yīng)用程序處理緩慢。

3.應(yīng)用程序掛起

有時特定的URL緩慢時，這是一回事。但是，當(dāng)IIS網(wǎng)站剛剛掛起并且所有或大多數(shù)網(wǎng)頁需要永久加載時，它不會變得更糟。通常，當(dāng)應(yīng)用程序過載或死鎖時，可能會掛起。.NET應(yīng)用程序通常會遇到兩種類型的應(yīng)用程序掛起方案。

硬掛(IIS問題)：這通常發(fā)生在請求處理管道的開始–在請求排隊的地方。由于應(yīng)用程序死鎖，所有可用線程都可能被阻塞，導(dǎo)致隨后的傳入請求最終在等待服務(wù)的隊列中結(jié)束。當(dāng)活動請求數(shù)超過IIS服務(wù)器上配置的并發(fā)限制時，也會發(fā)生這種情況。此類掛起將表現(xiàn)為請求超時并收到503 Service Unavailable錯誤。硬性影響所有URL和整個Web應(yīng)用程序本身。

有用的疑難解答提示：

• 不斷跟蹤IIS服務(wù)器中隊列中的請求數(shù)(Windows性能監(jiān)視器中為Http Service Request Queues \ ArrivalRate)。這決不能超過為工作進程配置的請求處理限制。
• 還跟蹤隊列中的請求等待時間(Windows性能監(jiān)視器中的Http Service Request Queues \ MaxQueueItemAge)。這將有助于檢測應(yīng)用程序是否面臨潛在的掛起。
• 還可以通過監(jiān)視IIS服務(wù)器事件來注意服務(wù)不可用和連接超時錯誤。

軟掛(ASP.NET問題)：這通常是由于特定段中的應(yīng)用程序代碼錯誤而造成的，僅影響幾個URL而不影響整個網(wǎng)站。通常，由ASP.NET控制器或頁面引起的掛起發(fā)生在

ExecuteRequestHandler

階段。為了確認(rèn)這一點，您可能想調(diào)試一下調(diào)試器，以確切了解請求被卡在哪里。檢查模塊名稱，階段名稱和URL。URL將指示導(dǎo)致掛起的控制器/頁面。

有用的疑難解答提示：

• 通過檢查Windows性能監(jiān)視器中的Http服務(wù)請求隊列\(zhòng) CurrentQueueSize計數(shù)器，驗證IIS是否是問題。如果為0，則IIS隊列中沒有任何請求。
• 如果不是IIS問題，則必須是ASP.NET控制器/頁面中的代碼級問題。
• 使用任何代碼分析，確定哪些URL掛起并獲得詳細(xì)的請求跟蹤。驗證請求掛起的模塊名稱和階段名稱，以確認(rèn)這是ASP.NET問題。
• 使用事務(wù)跟蹤工具[3]進行代碼分析可以幫助識別存在問題的確切代碼行。

4.頻繁垃圾回收暫停

當(dāng)托管堆上分配的對象使用的內(nèi)存超過應(yīng)用程序開發(fā)人員配置的可接受閾值時，.NET CLR中的垃圾回收(GC)會初始化。這是GC.Collect方法跳轉(zhuǎn)到動作并回收死對象占用的內(nèi)存的時候。CLR中的GC通常發(fā)生在存儲短期對象的第0代堆中。當(dāng)GC發(fā)生在包含長期對象的第二代堆中時，它稱為Full GC。每次發(fā)生GC都會在CLR上增加大量CPU負(fù)載，并減慢應(yīng)用程序的處理速度。因此，如果GC暫停時間更長且更頻繁，則應(yīng)用程序?qū)②呌诜啪彙?/p>

有用的疑難解答提示：

• 適當(dāng)調(diào)整GC堆內(nèi)存的大小，并確保已根據(jù)需要設(shè)置GC限制。
• 避免在不需要它們的地方使用對象和大字符串。
• 跟蹤GC的實例，GC花費的時間以及JVM花費的GC時間的百分比。
• 尋找發(fā)生完全GC的時間。這可能導(dǎo)致應(yīng)用程序變慢。
• 根據(jù)應(yīng)用程序需求明智地使用服務(wù)器GC或工作站GC。
• 端到端監(jiān)視CLR層以識別內(nèi)存使用情況，GC活動，CPU峰值等。

5.IIS服務(wù)器瓶頸

Microsoft IIS Server是.NET Framework的關(guān)鍵部分。IIS是Web服務(wù)器，它承載構(gòu)建于.NET上的Web應(yīng)用程序或網(wǎng)站，并運行W3WP進程，該進程負(fù)責(zé)響應(yīng)傳入的請求。IIS還集成了公共語言運行時(CLR)，該運行時負(fù)責(zé)為線程處理分配資源。由于IIS具有各種活動部分，因此IIS中的瓶頸可能會對.NET應(yīng)用程序性能產(chǎn)生直接的負(fù)面影響。

常見的IIS服務(wù)器問題：

• 由于內(nèi)存，CPU等資源的過度利用而導(dǎo)致服務(wù)器超載
• 高并發(fā)連接數(shù)和連接數(shù)下降
• 應(yīng)用程序池故障
• SSL證書已過期
• ASP.NET請求處理服務(wù)的高響應(yīng)時間
• 高CLR等待時間
• 緩存不正確
• HTTP錯誤，包括靜態(tài)和動態(tài)內(nèi)容錯誤以及連接錯誤

有用的疑難解答提示：

• 調(diào)整IIS服務(wù)器的大小，以便不存在資源爭用或資源過度利用的情況。
• 根據(jù)傳入請求的速率與更多IIS服務(wù)器進行負(fù)載平衡。
• 跟蹤SSL證書的有效性，并在證書過期之前主動發(fā)出警報。
• 監(jiān)視IIS性能[4]，應(yīng)用程序池，網(wǎng)站的所有方面，[5]并識別不正確的配置和性能偏差。

6.數(shù)據(jù)庫慢查詢

并非總是會影響應(yīng)用程序性能的.NET代碼問題。運行緩慢的查詢通常是常見的原因。但是通常是.NET應(yīng)用程序開發(fā)人員因應(yīng)用程序性能下降[6]而受到指責(zé)。

這樣做的原因是，SQL性能如何影響.NET應(yīng)用程序處理沒有上下文可見性。ADO.NET和ODP.NET連接問題可能是查詢處理緩慢的原因之一，但常見原因是查詢的格式不正確。執(zhí)行計劃不正確，索引缺失，架構(gòu)設(shè)計不當(dāng)，緩沖池較小，聯(lián)接缺失，緩存不正確，連接未正確進行池化等也是導(dǎo)致數(shù)據(jù)庫查詢處理受到影響的原因。

雖然DBA負(fù)責(zé)數(shù)據(jù)庫性能和查詢創(chuàng)建，但.NET應(yīng)用程序所有者需要在應(yīng)用程序處理期間跟蹤查詢級別的問題。這將有助于區(qū)分代碼級問題和數(shù)據(jù)庫問題，并且.NET開發(fā)人員不必花時間尋找代碼中的問題。

有用的疑難解答提示：

• 在應(yīng)用程序事務(wù)的上下文中監(jiān)視查詢處理以識別慢查詢。
• 適當(dāng)規(guī)劃數(shù)據(jù)庫的大小和配置，以確保一致的性能。
• 使用數(shù)據(jù)庫監(jiān)視工具[7]來識別和修復(fù)丟失的索引，通過重新索引來優(yōu)化數(shù)據(jù)庫布局等。
• 跟蹤數(shù)據(jù)庫與應(yīng)用程序的連接，以隔離所有連接問題。

溫馨提示：除了數(shù)據(jù)庫調(diào)用速度慢之外，由于外部調(diào)用[8](例如HTTP，Web Service，WCF)也可能導(dǎo)致速度慢[9]。

7.基礎(chǔ)設(shè)施故障：盡管不是.NET框架的問題，但仍是一個.NET問題!

.NET Framework不是獨立的層。使用.NET Framework的應(yīng)用程序?qū)⑴c基礎(chǔ)架構(gòu)(例如任何虛擬服務(wù)器，容器或云基礎(chǔ)架構(gòu))有很多依賴性。然后，可能會有后端存儲設(shè)備。盡管這些不是直接的.NET問題，但是這些基礎(chǔ)結(jié)構(gòu)組件中的任何一個問題都可能同樣影響.NET性能。

就像我們看到IIS服務(wù)器和數(shù)據(jù)庫可能遇到瓶頸一樣，VM可能會耗盡資源，SAN陣列可能會遇到無法處理的高IOPS，或者如果.NET應(yīng)用程序托管在Azure上，那么可能會有一個應(yīng)用程序服務(wù)運行不正常。

在大多數(shù)應(yīng)用程序環(huán)境中，與網(wǎng)絡(luò)相關(guān)的投訴都位居榜首。無論是網(wǎng)絡(luò)問題還是應(yīng)用程序問題之間總是存在責(zé)備游戲。網(wǎng)絡(luò)擁塞，丟包或設(shè)備故障可能會影響應(yīng)用程序的性能和連接性。

有用的疑難解答提示：

.NET應(yīng)用程序環(huán)境的總體性能保證要求應(yīng)用程序與支持基礎(chǔ)結(jié)構(gòu)之間的依存關(guān)系具有相關(guān)的可見性。確保實施融合的應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)監(jiān)視策略以捕獲基礎(chǔ)結(jié)構(gòu)問題。

當(dāng)您專注于捕獲和解決所有這些問題時，請務(wù)必記住，編寫干凈而高效的代碼可以解決.NET方面的許多問題。編寫良好的代碼，保持系統(tǒng)和基礎(chǔ)架構(gòu)的健康，并實施必要的工具以監(jiān)控自動化。這將幫助您提供高性能的.NET應(yīng)用程序和數(shù)字體驗。

References

[1] 應(yīng)用程序性能: https://www.eginnovations.com/blog/what-is-application-performance-monitoring/

[2] 代碼分析工具: https://www.eginnovations.com/microsoft-net-monitoring

[3] 事務(wù)跟蹤工具: https://www.eginnovations.com/microsoft-net-monitoring

[4] 監(jiān)視IIS性能: https://www.eginnovations.com/iis-monitoring

[5] 所有方面，: https://www.eginnovations.com/iis-monitoring

[6] 應(yīng)用程序性能下降: https://www.eginnovations.com/webinar/my-application-is-slow-troubleshooting-prevention/

[7] 數(shù)據(jù)庫監(jiān)視工具: https://www.eginnovations.com/database-monitoring

[8] 速度慢之外，由于外部調(diào)用: https://www.eginnovations.com/microsoft-net-monitoring#supported

[9] 速度慢: https://www.eginnovations.com/microsoft-net-monitoring#supported