保存Web應用程序中各個層的歷史性能數(shù)據(jù),有利于快速確定問題所在位置。典型的三層架構(gòu)包括Web層、應用層和數(shù)據(jù)層。性能問題有可能出現(xiàn)在任一層,因而此舉會增加排查問題的難度。通過保存各個層的性能數(shù)據(jù),我們就有可能在最終用戶遇到問題之前就檢測并解決掉,或者,更關(guān)鍵的是,在這些問題影響到網(wǎng)站或應用中與收益相關(guān)的功能之前就將它們排除。Web開發(fā)人員必須與運維人員一起協(xié)作,監(jiān)控各層的運行狀況,確定各層的測試方式應該是兩個團隊的共同職責。例如,Web開發(fā)人員可能負責保存應用層和Web層的歷史性能趨勢數(shù)據(jù),因此在如何測試這些層及執(zhí)行這些層的測試上有更多的話語權(quán)。另一方面,在數(shù)據(jù)層中,可能應該由數(shù)據(jù)庫管理員來創(chuàng)建工具或測試特定的查詢和數(shù)據(jù)庫功能。
對于通過網(wǎng)站來獲得收益或占領(lǐng)市場的公司而言,監(jiān)控最終用戶的性能絕對是最重要的。如果不知道網(wǎng)站在一個國家或全球范圍內(nèi)的運行狀況,那么這個公司可能就無法管理好自己的核心業(yè)務。然而,如果想要快速高效地診斷問題,并且控制好影響最終用戶性能的各個層或組件,僅僅監(jiān)控最終用戶的性能還是不夠的。
一個典型的三層Web環(huán)境,它部署了一個全球或地區(qū)性的性能監(jiān)控服務,所以這家公司可以跟蹤最終用戶和Web性能指標。
Web應用的各個組件的每一層上只有少數(shù)監(jiān)控或完全沒有監(jiān)控。當全球監(jiān)控服務在最終用戶層上發(fā)現(xiàn)問題時,開發(fā)和運維團隊就必須倉促地搜索日志,才能夠發(fā)現(xiàn)性能問題到底出現(xiàn)在什么位置。在這個例子中,當有一個修改影響到全部三層時,最終用戶的性能體驗就會嚴重下降。
事實上,這個問題可能是由外部因素導致的,如DDos攻擊、網(wǎng)絡或ISP問題,或者是訪客的激增。然而,由于現(xiàn)在沒有關(guān)于各層執(zhí)行情況的歷史數(shù)據(jù),所以他們很難確定問題的根源在哪里,因此需要花費更多的時間和精力去尋找問題的根源。
相同的環(huán)境,但是現(xiàn)在有了每層的歷史性能數(shù)據(jù)。在這種情況下,如果有一個內(nèi)部修改導致最終用戶性能下降或出現(xiàn)問題,那么它幾乎可以馬上被檢測出來。修復網(wǎng)站制作問題所需要的時間顯著減少,因為現(xiàn)在性能變化可以在更細的粒度上檢測出來了,而且檢測問題發(fā)生的位置也被縮小到特定的層次上。性能數(shù)據(jù)可以與修改記錄和應用日志文件進行比較,由此一來,隔離問題發(fā)生位置就毫無難度了。此外,當有一位最終用戶遇到性能問題時,相關(guān)人員只需要在辦公地查看一些歷史性能圖表,就可以確定引起問題的是內(nèi)部因素還是外部因素。