APP終端用戶總在抱怨應(yīng)用遲鈍，老板也為此苦惱。而這種壓力，恰恰成為運(yùn)維部門徹底修復(fù)應(yīng)用的動(dòng)力。可從哪兒著手呢?讓我們先來分析一下**常見的五種導(dǎo)致應(yīng)用緩慢的原因，然后再對癥下藥，找到并修復(fù)它們吧!

#1 客戶端緩慢

問題：當(dāng)今基于web的應(yīng)用傾向于將用戶交互工作(通常伴隨大量數(shù)據(jù))推送到客戶端工作站。從那里，JavaScript代碼會(huì)處理成百上千行的數(shù)據(jù)，而這些數(shù)據(jù)，在客戶端顯示更新前會(huì)導(dǎo)致數(shù)秒的停頓。

解決方案：借助高質(zhì)量的應(yīng)用性能管理(APM)系統(tǒng)，比如SteelCentral AppResponse，可以很輕松地發(fā)現(xiàn)具有此類內(nèi)部處理延遲的客戶端，并區(qū)分是應(yīng)用暫停還是人類“思考時(shí)間”延遲。

#2 服務(wù)器緩慢

問題：服務(wù)器團(tuán)隊(duì)不喜歡聽到應(yīng)用性能緩慢是由服務(wù)器緩慢引起的這類指責(zé)，但是引起應(yīng)用性能緩慢的**常見原因就是應(yīng)用或服務(wù)器本身，而不是網(wǎng)絡(luò)。

現(xiàn)代應(yīng)用通常部署在多層基礎(chǔ)設(shè)施上：

? 前端Web服務(wù)器與應(yīng)用服務(wù)器進(jìn)行對話，應(yīng)用服務(wù)器與查詢一個(gè)或多個(gè)數(shù)據(jù)庫服務(wù)器的中間件服務(wù)器進(jìn)行對話

? 然后，這些服務(wù)器都可能會(huì)與DNS服務(wù)器進(jìn)行通信，以查找IP地址或?qū)⑵溆成浠胤?wù)器名稱上

當(dāng)這種情況發(fā)生時(shí)，只有一個(gè)薄弱環(huán)節(jié)會(huì)使整個(gè)應(yīng)用變慢。

解決方案：為了發(fā)現(xiàn)問題的根源，我們必須了解一個(gè)應(yīng)用中多個(gè)組件之間的交互情況。這一過程被稱作應(yīng)用依賴關(guān)系映射(ADM)，用已有的監(jiān)測解決方案所提供的信息作為APM集成方案的一部分。

幸運(yùn)的是，網(wǎng)絡(luò)為ADM提供了一個(gè)非常有利的位置，這意味著網(wǎng)絡(luò)團(tuán)隊(duì)在很大程度上為應(yīng)用和服務(wù)器團(tuán)隊(duì)提供幫助。但需要記住一點(diǎn)，借助數(shù)據(jù)包捕獲工具來確定是網(wǎng)絡(luò)還是應(yīng)用的問題可能需要花費(fèi)很多時(shí)間。

為了節(jié)省時(shí)間，某些**的應(yīng)用性能管理系統(tǒng)可以快速方便地找出導(dǎo)致應(yīng)用性能遲緩的根源。一旦建立起適當(dāng)?shù)谋O(jiān)測點(diǎn)和基本配置，就能即刻帶來投資回報(bào)且便于使用。此外，收集到的信息還可以為APM軟件提供了自動(dòng)繪制關(guān)鍵應(yīng)用依賴關(guān)系圖所需的輸入。

#3 小型數(shù)據(jù)庫

問題：在帶有小數(shù)據(jù)集的快速局域網(wǎng)上開發(fā)的應(yīng)用在實(shí)驗(yàn)室中似乎運(yùn)行得很順利。然而，一旦投入生產(chǎn)網(wǎng)絡(luò)，一切就都不復(fù)存在了。而且，隨著數(shù)據(jù)庫的不斷增長，宕機(jī)時(shí)間也會(huì)不斷加長。

解決方案：在此情況下，使用新型APM解決方案進(jìn)行快速分析，可能會(huì)看到一個(gè)關(guān)鍵的中間件服務(wù)器正在多次向數(shù)據(jù)庫服務(wù)器發(fā)出請求。實(shí)際上，只有一個(gè)客戶端請求就可能會(huì)引發(fā)多個(gè)數(shù)據(jù)庫請求或傳輸大量的數(shù)據(jù)。更簡單高效的數(shù)據(jù)庫查詢通常能夠解決這個(gè)問題。

在另一個(gè)實(shí)例中，數(shù)據(jù)庫服務(wù)器可能需要花費(fèi)幾秒鐘的時(shí)間才能將數(shù)據(jù)返回到中間件或應(yīng)用服務(wù)器中。然后，應(yīng)用團(tuán)隊(duì)可以使用APM系統(tǒng)來識別違規(guī)查詢。

#4 頻繁對話

問題：應(yīng)用遲緩的另一個(gè)常見原因是頻繁對話：一個(gè)應(yīng)用服務(wù)器，或是客戶端本身，會(huì)代表運(yùn)行該應(yīng)用的人員發(fā)出很多小的請求來執(zhí)行一次交易。

然而，隨著虛擬化技術(shù)的出現(xiàn)，服務(wù)器團(tuán)隊(duì)可能已經(jīng)將服務(wù)器映像自動(dòng)遷移到輕載主機(jī)。這可能會(huì)將服務(wù)器映像移動(dòng)到遠(yuǎn)離其他服務(wù)器或磁盤存儲系統(tǒng)幾毫秒的位置。而且毫秒可以快速堆積。

解決方案：要解決此問題，需要掌握系統(tǒng)之間和系統(tǒng)連接到網(wǎng)絡(luò)的請求數(shù)量，以及請求之間的延遲情況。

#5 網(wǎng)絡(luò)服務(wù)遲緩

問題：**，網(wǎng)絡(luò)服務(wù)遲緩會(huì)降低應(yīng)用性能，但這并不涉及到網(wǎng)絡(luò)本身，而是大多數(shù)基于網(wǎng)絡(luò)的應(yīng)用所依賴的服務(wù)。

想象一個(gè)對不存在的主DNS服務(wù)器進(jìn)行查詢的應(yīng)用。在沒有響應(yīng)的情況下，應(yīng)用在嘗試查詢**個(gè)DNS服務(wù)器之前必須超時(shí)**個(gè)請求。在這種情況下，應(yīng)用會(huì)周期性變慢，但卻在其他時(shí)間運(yùn)行良好。

解決方案：像這樣的間歇性問題通常會(huì)很難診斷，但這卻是像SteelCentral AppResponse這樣的APM系統(tǒng)的用武之地，它能持續(xù)監(jiān)測和記錄所有交易。只需確定性能緩慢的時(shí)間，并找出數(shù)據(jù)中問題的根源，接下來修復(fù)它們只是分分鐘事。