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