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

#1 客戶端緩慢

問題：當(dāng)今基于web的應(yīng)用傾向于將用戶交互工作(通常伴隨大量數(shù)據(jù))推送到客戶端工作站。從那里,，JavaScript代碼會處理成百上千行的數(shù)據(jù),，而這些數(shù)據(jù)，在客戶端顯示更新前會導(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ù)器都可能會與DNS服務(wù)器進(jìn)行通信,，以查找IP地址或?qū)⑵溆成浠胤?wù)器名稱上

當(dāng)這種情況發(fā)生時(shí)，只有一個(gè)薄弱環(huán)節(jié)會使整個(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軟件提供了自動繪制關(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í)間也會不斷加長,。

解決方案：在此情況下,，使用新型APM解決方案進(jìn)行快速分析，可能會看到一個(gè)關(guān)鍵的中間件服務(wù)器正在多次向數(shù)據(jù)庫服務(wù)器發(fā)出請求,。實(shí)際上,，只有一個(gè)客戶端請求就可能會引發(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ù)器，或是客戶端本身,，會代表運(yùn)行該應(yīng)用的人員發(fā)出很多小的請求來執(zhí)行一次交易,。

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

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

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

問題：**,，網(wǎng)絡(luò)服務(wù)遲緩會降低應(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)用會周期性變慢，但卻在其他時(shí)間運(yùn)行良好,。

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