網站響應時間是指系統對請求做出響應的時間。通俗來說就是咱們把網址輸入進瀏覽器而後敲回車鍵開始一直到瀏覽器把網站的內容呈現給用戶的這段時間。網站響應時間是越短越好,由於網站頁面打開速度越快,就意味着咱們的用戶能夠更快的訪問站點或者咱們的服務器。通常咱們網站的響應時間保持在100~1000ms便可。1m=1000ms,打開速度越快對用戶體驗度越好。聽說響應時間還會影響到網站SEO效果(請行業專家留言告訴我)。css
響應時間並不能直接反映網站性能的高低,可是在必定程度上反應了網站系統的處理能力,也是給用戶最直觀上的感覺。若是網站的響應時間過長,好比10秒以上,用戶的流失率會大大增長,因此把響應時間控制在必定範圍內是提升用戶體驗度的第一要素。程序員
當用戶請求一個網站數據的時候,其實是發送了一個http請求,在宏觀上能夠分爲兩個部分:redis
1. http請求到達目標網站服務器以前sql
2. http請求到達目標網站服務器以後數據庫
若是忽略其中硬件部分和部分細節,請求一個網站數據的大致過程以下圖所示(其中CDN和緩存部分能夠省略): 瀏覽器
咱們要想縮短一個網站的響應時間,本質上是提升數據的返回速度,說的直白一點就是要把請求數據過程當中的各個步驟提升速度,這樣總體下來響應時間就會縮短。緩存
把數據放在離用戶越近的地方響應時間越快服務器
客戶端是發起一個網站請求的源頭,其實這個源頭能夠施加必定的策略來大大縮短某些數據的獲取時間。其中最爲經常使用的就是緩存,一些經常使用的,不多變更的資源緩存在客戶端,不但能縮短獲取資源的時間,並且在很大程度上能減輕服務端的壓力。好比一些圖片,css,js文件,甚至一些接口的數據或者整個網頁內容均可以在客戶端作緩存。另外http請求的合併也能夠減小對服務端的請求次數,在必定程度上能夠縮短請求的響應時間。網絡
通常網站的訪問方式都採用域名的方式(不多見IP方式),既然是域名就涉及到DNS解析速度的問題,若是DNS服務解析的速度比較慢,總體過程的響應時間也會加長,不過這個過程其實不多出現慢的問題(不是說沒有)。併發
客戶端獲取到網站IP以後經過網卡把Http請求發送出去,目標地址爲相應的網站服務器。在這個過程中若是客戶端和服務器端有一方帶寬比較小的話,就會加大響應時間。我司曾經就由於服務器帶寬太小致使客戶端響應時間很長的狀況,當時排查了很長時間才發現。
固然網絡是不可靠的,這個過程的響應時間其實取決於不少因素,好比路由器的路由策略是否最優,整個過程經過的網關數據量等。因此有不少網站實際上是多地區多機房部署的,目的就是爲了讓用戶經過很短的網絡路徑就能到達網站(其實這個過程運營商的選擇也有影響)。
當一個請求到達網站服務器,服務器便開始處理請求,通常會有專門處理業務請求的一個業務層,有的體現爲rpc協議的微服務,有的體現爲簡單的一個代碼分層。最終請求的數據會經過查詢數據庫來返回。其實這個過程和車站購票流程同樣,每一個窗口的處理能力是有限的,對應到服務器處理能力。因爲這個緣由,因此誕生了負載均衡的策略,核心思想就是:分。一臺服務器不夠,那就兩臺,三臺,四臺..... 直到併發的全部請求的響應時間都在可控範圍以內。
數據庫的狀況相似,一個數據庫扛不住壓力,就加到N個數據庫分散壓力。一個表扛不住壓力,就把這個表拆分開,拆分紅多個表,甚至拆分到多個不一樣服務器數據庫,這就是咱們經常使用的拆表策略。有的時候在同一個數據庫中進行表拆分,性能的提高並不是最大化,由於一臺服務器的磁盤IO是有上限的,就算拆成100個表,仍是在同一個物理磁盤上,固然這樣可緩解鎖單表的狀況。
如今有不少的場景採用NOsql代替關係型數據庫來縮短響應時間,在正常狀況下,因爲關係型數據庫的自己因素在特定場景下的讀寫速度比Nosql要慢不少,因此係統設計初期,能夠考慮採用關係型數據庫和Nosql混用的方案。
當併發的請求到達必定程度,瓶頸大部分狀況下發生在DB層面,甚至DB不管怎麼優化總有上限。爲了不頻繁查詢數據庫產生瓶頸,誕生了緩存。在訪問數據庫以前加入了緩存層,固然這裏的緩存採用的方案在數據的響應時間上要比數據庫小不少,好比經常使用的redis,Memcache,可是這些第三方的緩存組件仍是要走網絡,比起進程內的緩存仍是要慢的多。
如今通常流行的設計在網站層和服務層都有緩存策略,只不過緩存的數據和策略有所不一樣,可是最終目的都是爲了加快請求的響應。固然加了緩存以後,數據的一致性須要仔細設計才能夠,若是發生數據不一致的狀況,程序員可能要背鍋了。
緩解數據庫壓力並非引入緩存的惟一因素。
一些小廠可能用不到cdn,可是cdn帶來的加速仍是很客觀的。cdn依靠部署在各地的邊緣服務器,經過中心平臺的負載均衡、內容分發、調度等功能模塊,使用戶就近獲取所需內容,下降網絡擁塞,提升用戶訪問響應速度和命中率。CDN就是把離用戶最近的數據返回給用戶。
程序異步化其實並不能縮短響應時間,可是對提升吞吐量有很大做用。