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

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

新聞名稱：怎么逐層保存網站歷史性能數據？
當前網址：http://m.newbst.com/news25/146025.html

成都網站建設公司_創新互聯，為您提供做網站、云服務器、小程序開發、軟件開發、電子商務、微信公眾號

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯