保存Web應(yīng)用程序中各個層的歷史性能數(shù)據(jù)，有利于快速確定問題所在位置。典型的三層架構(gòu)包括Web層、應(yīng)用層和數(shù)據(jù)層。性能問題有可能出現(xiàn)在任一層，因而此舉會增加排查問題的難度。通過保存各個層的性能數(shù)據(jù)，我們就有可能在最終用戶遇到問題之前就檢測并解決掉，或者，更關(guān)鍵的是，在這些問題影響到網(wǎng)站或應(yīng)用中與收益相關(guān)的功能之前就將它們排除。Web開發(fā)人員必須與運(yùn)維人員一起協(xié)作，監(jiān)控各層的運(yùn)行狀況，確定各層的測試方式應(yīng)該是兩個團(tuán)隊的共同職責(zé)。例如，Web開發(fā)人員可能負(fù)責(zé)保存應(yīng)用層和Web層的歷史性能趨勢數(shù)據(jù)，因此在如何測試這些層及執(zhí)行這些層的測試上有更多的話語權(quán)。另一方面，在數(shù)據(jù)層中，可能應(yīng)該由數(shù)據(jù)庫管理員來創(chuàng)建工具或測試特定的查詢和數(shù)據(jù)庫功能。


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