不可忽視的 .NET 應用5大性能問題

【編者按】本文系國內 ITOM 管理平臺 OneAPM 翻譯自 Steven Haines 的文章。Steven Haines 是 Pisksel 技術架構師，目前在奧蘭多迪士尼樂園工做。他是在線教育網站 geekcap.com 的創始人，著有上百篇 Java 相關的文章以及三本 Java 著做：《Java 2 From Scratch》《Java 2 Primer Plus》以及《Pro Java EE Performance Management and Optimization》

實現有效 APM 策略所面臨的挑戰：

• 代碼依賴
• 過分或沒必要要的日誌
• 同步與鎖
• 潛在數據庫問題
• 潛在的基礎架構問題

###一、代碼依賴

開發程序是一項具備挑戰性的工做。你不只要爲了知足商業需求而創建程序邏輯，還要選擇最合適的代碼庫和工具來幫助你。你能想象本身建立全部的日誌管理代碼，XML 和 JSON 解析邏輯，或全部的序列化庫麼？你固然能夠編寫代碼來完成這些事，可是諸多開源開發者團隊已經作好了這些事情，你又何須親力親爲呢？此外，若是你正在與第三方系統集成，你會本身讀完專有的通訊協議規範，仍是購買供應商提供的庫幫你完成呢？

我相信你會贊成：若是有人已經解決了你的問題，使用他的解決辦法會比本身想辦法解決效率更高。若是這是一個已經被許多公司採用的開源項目，那麼極可能它已經通過完備的測試，文檔充足，並且你應該找獲得許多使用教程。

然而，使用依賴庫是有危險的。你須要回答如下問題：

• 這個庫真的寫得很好而且已經充分測試了嗎？
• 你是否用與衆多公司同樣的方式使用這個庫？
• 你的使用方式是否正確？

請確保在選擇外部庫以前進行一些調查，若是你對某個庫的性能有什麼疑問，那就進行一些性能測試。開源項目很好的地方在於你能夠訪問它們的所有源代碼以及測試套件和構建流程。下載它們的源代碼，執行編譯過程，並查看測試結果。若是你看到很高的測試覆蓋率，那麼就能夠比沒有測試案例時信心百倍！

最後，確保正確地使用依賴庫。若是正確使用，ORM 工具的確可以大大提升性能。ORM 工具的問題在於，若是你不花時間去學習如何正確地使用它，你就會輕易的砸本身腳，破壞本身的應用性能。關鍵就在於若是不花時間學習這些工具，本應幫助你的工具反而會傷害你。

###二、過分或沒必要要的日誌

日誌記錄是調試工具庫裏的強大武器，能夠幫助你識別應用執行過程當中在特定時間內可能發生的異常。當錯誤發生時，捕捉錯誤信息並收集儘量多的上下文信息是很是重要的。然而，簡潔地捕捉錯誤條件和過分記錄之間是有差異的。

最廣泛的兩個問題就是：

• 多級別異常日誌
• 錯誤配置生產日誌級別

異常日誌能幫助你瞭解應用程序中發生的問題，於是很是重要。但一個常見的問題是，應用程序全部層級的異常都進行記錄。例如，你的某個數據訪問對象捕獲到一個數據庫異常，並將該異常傳達到服務層。服務層可能會捕捉該異常，並將其傳達到網絡層。若是咱們在數據層、服務層和網絡層上都記錄該異常，那麼咱們對此相同的錯誤條件就有三條堆棧記錄。這會致使寫入日誌文件的額外負擔，還會使日誌文件充滿冗餘信息。但這個問題很是廣泛，我敢斷言，若是你檢查本身的日誌文件，你極可能會發現多個這樣的例子。

生產應用中常見的另外一個大的日誌問題與日誌級別有關。.NET 日誌記錄器定義瞭如下日誌記錄級別（.NET TraceLevel 與 log4net 中的命名會有所不一樣，但絕對類似）：

• Off

• Fatal

• Error

• Warning

• Info

• Verbose / Debug

在生產應用程序中，你應該只記錄 error 或 fetal 級別的日誌語句，在更寬鬆的環境中，捕捉 warning 甚至 info 級別的日誌信息也徹底能夠，可是一旦應用投入生產環境，用戶負載將迅速填滿日誌並使應用程序陷入癱瘓。若是你不經意地將生產環境下的應用日誌級別設爲 debug，應用的響應時間比正常狀況下高兩或三倍都不奇怪！

三、同步與鎖

有時候，你想確保應用代碼中每次只有一個線程執行一段代碼子集。 例如，讀取單線程規則執行組件之類的共享軟件資源，以及文件句柄或網絡鏈接之類的共享基礎架構資源。.NET 框架提供了許多不一樣類型的同步策略，包括鎖/監視器、進程間互斥，和讀/寫鎖這類的專用鎖。

無論你爲何要同步代碼或者選擇什麼機制實現代碼同步，都會致使一個問題：那就是有部分代碼一次只能由一個線程執行。 設想去超市，只有一個收銀員在工做：許多人進入商店，瀏覽商品，將商品放進購物車裏，但某一時候，他們不得不排隊以進行支付。在這個例子中，購物是多線程的，每一個人都表明一個線程。然而結帳是單線程的，這意味着每一個人都要花費排隊付款的時間。這個過程如圖1所示。

圖1：線程同步

咱們有七個線程，都須要訪問一段同步代碼塊，因此它們依次得到權限訪問該代碼塊，執行其功能，而後繼續。

在圖2中總結了線程同步的過程。

圖2 線程同步過程

首先，爲特定的對象（System.Object 派生）建立鎖，意味着當一個線程試圖進入同步代碼塊時必須獲取該同步對象的鎖。若是該鎖可用，則該線程被授予執行同步代碼的權限。在圖2中的例子中，當第二個線程到達時，第一個線程已經佔有了該鎖，因此第二個線程被強制等待，直到第一個線程執行完畢。當第一個線程執行結束時，會釋放該鎖，而後第二個線程被授予訪問權限。

正如你可能猜想到的，線程同步將給 .NET 應用帶來一個極大的挑戰。咱們設計應用程序時，但願其能支持數十個甚至數百個同步請求，但線程同步會把全部處理這些請求的線程串行化，致使性能瓶頸！

解決的辦法有兩種：

• 仔細檢查同步的代碼，以肯定是否存在其餘可行辦法
• 限制同步代碼塊的範圍

有時候，你要訪問必須同步的共享資源，但不少時候，你能夠用徹底避免同步的方法從新解決該問題。例如，咱們以前使用的規則過程引擎有單線程的要求，所以拖慢了程序中全部請求的執行速度。這顯然是一個設計上的缺陷，咱們能夠用一個能夠並行工做的庫取代之。你須要問本身是否有更好的選擇：若是你在往一個本地文件系統寫入信息，你是否能夠把信息發送給某項服務，再由該服務將信息存儲到數據庫中？你是否能夠將對象設爲不可變，從而不管是否有多線程訪問它都不要緊？等等，等等…

對於那些必需要同步的代碼段，請合理地選擇鎖。你的目標是將同步代碼塊隔離以知足最低限度的同步要求。一般最好是定義一個特定的對象進行同步，而不是對包含同步代碼的對象進行同步，由於你可能會在不經意間拖慢該對象的其餘交互。最後，考慮使用讀/寫鎖，而不是標準的鎖，這樣，你能夠在資源只進行同步變化時，容許讀操做。

###4.潛在的數據庫問題

幾乎全部的內容應用最終都會涉及到向/從數據庫或文檔存儲儲存/檢索數據。所以，數據庫、數據庫查詢，以及存儲過程調優對應用程序的性能來講是最重要的。

程序架構師/開發人員和數據庫架構師/開發人員之間有一個哲學性的劃分。應用程序架構師傾向於認爲全部的業務邏輯都應該駐留在應用程序中，數據庫應該只提供訪問數據的通道。另外一方面，數據庫架構師更傾向於認爲將業務邏輯推到數據庫中更有益提升性能。這個劃分的答案極可能就是介於二者之間。

做爲一個應用程序架構師，我傾向於將更多的業務邏輯應用在程序當中，但我徹底認可數據庫架構師能更好的理解數據和與數據交互的最佳方式。我認爲，這兩個羣體之間的協同合做才能產生最佳的解決方案。可是，無論你傾向於哪一方，請確保你的數據庫架構師檢查你的數據模型，全部的查詢語句和存儲過程，他們都有豐富的知識幫助你以最佳的方式來調整和配置數據庫，他們有大量的工具能夠爲你調整查詢語句。例如，有一些工具可用於 SQL 調優，遵循如下這些步驟：

• 分析 SQL 語句
• 肯定查詢的執行計劃
• 利用人工智能生成備選的 SQL 語句
• 肯定全部備選方案的執行計劃
• 提出最佳的查詢方式來完成目標

當我在寫數據庫查詢代碼時，我使用了這類工具，並在高負載狀況下量化告終果，一些細微的調整和優化，都能致使極大的性能提高。

###五、潛在的基礎架構問題

以前提過，.NET 應用運行在分層的環境中，其層級結構如圖3所示：

圖3.NET分層執行模型

你的應用程序運行在 ASP.NET 或是 Windows Forms 容器中，使用 ADO 庫與運行在 CLR 內部的數據庫交互，而 CLR 運行在操做系統中，操做系統又運行在硬件裏。而該硬件又與其餘包含不一樣技術堆棧的硬件經過網絡相連。在你的應用與外部環境之間，以及在應用的組件之間，一般有多個負載平衡器。咱們還有 API 管理服務以及多級緩存。全部這一切，都是爲了說明，基礎構造數量龐雜，均可能影響應用程序的性能！

所以，你必須細緻地調整基礎架構。檢查你的應用組件和數據庫所運行的操做系統和硬件設備，以確保它們的最佳表現。測量服務器之間的網絡延遲，並確保你有足夠的帶寬來知足應用程序之間的交互。檢查緩存，確保較高的緩存命中率。分析負載平衡器的行爲以確保請求很快地分發到全部可用的服務器。總之，你須要全面檢查應用程序的性能，既包括應用業務交易也包括支持它們的基礎架構。

OneAPM 助您輕鬆鎖定 .NET 應用性能瓶頸，經過強大的 Trace 記錄逐層分析，直至鎖定行級問題代碼。以用戶角度展現系統響應速度，以地域和瀏覽器維度統計用戶使用狀況。想閱讀更多技術文章，請訪問 OneAPM 官方博客。 本文轉自 OneAPM 官方博客