APP終端用戶總在抱怨應用遲鈍，老板也為此苦惱。而這種壓力，恰恰成為運維部門徹底修復應用的動力。可從哪兒著手呢?讓我們先來分析一下**常見的五種導致應用緩慢的原因，然后再對癥下藥，找到并修復它們吧!
#1 客戶端緩慢
問題：當今基于web的應用傾向于將用戶交互工作(通常伴隨大量數據)推送到客戶端工作站。從那里，JavaScript代碼會處理成百上千行的數據，而這些數據，在客戶端顯示更新前會導致數秒的停頓。
解決方案：借助高質量的應用性能管理(APM)系統，比如SteelCentral AppResponse，可以很輕松地發現具有此類內部處理延遲的客戶端，并區分是應用暫停還是人類“思考時間”延遲。
#2 服務器緩慢
問題：服務器團隊不喜歡聽到應用性能緩慢是由服務器緩慢引起的這類指責，但是引起應用性能緩慢的**常見原因就是應用或服務器本身，而不是網絡。
現代應用通常部署在多層基礎設施上：
? 前端Web服務器與應用服務器進行對話，應用服務器與查詢一個或多個數據庫服務器的中間件服務器進行對話
? 然后，這些服務器都可能會與DNS服務器進行通信，以查找IP地址或將其映射回服務器名稱上
當這種情況發生時，只有一個薄弱環節會使整個應用變慢。
解決方案：為了發現問題的根源，我們必須了解一個應用中多個組件之間的交互情況。這一過程被稱作應用依賴關系映射(ADM)，用已有的監測解決方案所提供的信息作為APM集成方案的一部分。
幸運的是，網絡為ADM提供了一個非常有利的位置，這意味著網絡團隊在很大程度上為應用和服務器團隊提供幫助。但需要記住一點，借助數據包捕獲工具來確定是網絡還是應用的問題可能需要花費很多時間。
為了節省時間，某些**的應用性能管理系統可以快速方便地找出導致應用性能遲緩的根源。一旦建立起適當的監測點和基本配置，就能即刻帶來投資回報且便于使用。此外，收集到的信息還可以為APM軟件提供了自動繪制關鍵應用依賴關系圖所需的輸入。
#3 小型數據庫
問題：在帶有小數據集的快速局域網上開發的應用在實驗室中似乎運行得很順利。然而，一旦投入生產網絡，一切就都不復存在了。而且，隨著數據庫的不斷增長，宕機時間也會不斷加長。
解決方案：在此情況下，使用新型APM解決方案進行快速分析，可能會看到一個關鍵的中間件服務器正在多次向數據庫服務器發出請求。實際上，只有一個客戶端請求就可能會引發多個數據庫請求或傳輸大量的數據。更簡單高效的數據庫查詢通常能夠解決這個問題。
在另一個實例中，數據庫服務器可能需要花費幾秒鐘的時間才能將數據返回到中間件或應用服務器中。然后，應用團隊可以使用APM系統來識別違規查詢。
#4 頻繁對話
問題：應用遲緩的另一個常見原因是頻繁對話：一個應用服務器，或是客戶端本身，會代表運行該應用的人員發出很多小的請求來執行一次交易。
然而，隨著虛擬化技術的出現，服務器團隊可能已經將服務器映像自動遷移到輕載主機。這可能會將服務器映像移動到遠離其他服務器或磁盤存儲系統幾毫秒的位置。而且毫秒可以快速堆積。
解決方案：要解決此問題，需要掌握系統之間和系統連接到網絡的請求數量，以及請求之間的延遲情況。
#5 網絡服務遲緩
問題：**，網絡服務遲緩會降低應用性能，但這并不涉及到網絡本身，而是大多數基于網絡的應用所依賴的服務。
想象一個對不存在的主DNS服務器進行查詢的應用。在沒有響應的情況下，應用在嘗試查詢**個DNS服務器之前必須超時**個請求。在這種情況下，應用會周期性變慢，但卻在其他時間運行良好。
解決方案：像這樣的間歇性問題通常會很難診斷，但這卻是像SteelCentral AppResponse這樣的APM系統的用武之地，它能持續監測和記錄所有交易。只需確定性能緩慢的時間，并找出數據中問題的根源，接下來修復它們只是分分鐘事。
|
