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


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