定義

網站響應時間是指系統對請求作出響應的時間。通俗來講就是我們把網址輸入進瀏覽器然后敲回車鍵開始一直到瀏覽器把網站的內容呈現給用戶的這段時間。網站響應時間是越短越好，因為網站頁面打開速度越快，就意味著我們的用戶可以更快的訪問站點或者我們的服務器。一般我們網站的響應時間保持在100~1000ms即可。1m=1000ms，打開速度越快對用戶體驗度越好。據說響應時間還會影響到網站SEO效果（請行業專家留言告訴我）。

創新互聯建站堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網站建設、網站設計、企業官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯網時代的前進網站設計、移動媒體設計的需求，幫助企業找到有效的互聯網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！

響應時間并不能直接反映網站性能的高低，但是在一定程度上反應了網站系統的處理能力，也是給用戶最直觀上的感受。如果網站的響應時間過長，比如10秒以上，用戶的流失率會大大增加，所以把響應時間控制在一定范圍內是提高用戶體驗度的第一要素。

解決方案

當用戶請求一個網站數據的時候，實際上是發送了一個http請求，在宏觀上可以分為兩個部分：

• 1. http請求到達目標網站服務器之前

• 2. http請求到達目標網站服務器之后

如果忽略其中硬件部分和部分細節，請求一個網站數據的大體過程如下圖所示（其中CDN和緩存部分可以省略）：

我們要想縮短一個網站的響應時間，本質上是提高數據的返回速度，說的直白一點就是要把請求數據過程中的各個步驟提高速度，這樣整體下來響應時間就會縮短。

把數據放在離用戶越近的地方響應時間越快

客戶端

客戶端是發起一個網站請求的源頭，其實這個源頭可以施加一定的策略來大大縮短某些數據的獲取時間。其中最為常用的就是緩存，一些常用的，很少變動的資源緩存在客戶端，不但能縮短獲取資源的時間，而且在很大程度上能減輕服務端的壓力。比如一些圖片，css，js文件，甚至一些接口的數據或者整個網頁內容都可以在客戶端做緩存。另外http請求的合并也可以減少對服務端的請求次數，在一定程度上可以縮短請求的響應時間。

DNS

一般網站的訪問方式都采用域名的方式（很少見IP方式），既然是域名就涉及到DNS解析速度的問題，如果DNS服務解析的速度比較慢，整體過程的響應時間也會加長，不過這個過程其實很少出現慢的問題（不是說沒有）。

網絡

客戶端獲取到網站IP之后通過網卡把Http請求發送出去，目標地址為相應的網站服務器。在這個過程當中如果客戶端和服務器端有一方帶寬比較小的話，就會加大響應時間。我司曾經就因為服務器帶寬過小導致客戶端響應時間很長的情況，當時排查了很長時間才發現。

當然網絡是不可靠的，這個過程的響應時間其實取決于很多因素，比如路由器的路由策略是否最優，整個過程通過的網關數據量等。所以有很多網站其實是多地區多機房部署的，目的就是為了讓用戶通過很短的網絡路徑就能到達網站（其實這個過程運營商的選擇也有影響）。

網站

當一個請求到達網站服務器，服務器便開始處理請求，一般會有專門處理業務請求的一個業務層，有的體現為rpc協議的微服務，有的體現為簡單的一個代碼分層。最終請求的數據會通過查詢數據庫來返回。其實這個過程和車站購票流程一樣，每個窗口的處理能力是有限的，對應到服務器處理能力。由于這個原因，所以誕生了負載均衡的策略，核心思想就是：分。一臺服務器不夠，那就兩臺，三臺，四臺..... 直到并發的所有請求的響應時間都在可控范圍之內。

數據庫的情況類似，一個數據庫扛不住壓力，就加到N個數據庫分散壓力。一個表扛不住壓力，就把這個表拆分開，拆分成多個表，甚至拆分到多個不同服務器數據庫，這就是我們常用的拆表策略。有的時候在同一個數據庫中進行表拆分，性能的提升并非大化，因為一臺服務器的磁盤IO是有上限的，就算拆成100個表，還是在同一個物理磁盤上，當然這樣可緩解鎖單表的情況。

現在有很多的場景采用NOsql代替關系型數據庫來縮短響應時間，在正常情況下，由于關系型數據庫的本身因素在特定場景下的讀寫速度比Nosql要慢很多，所以系統設計初期，可以考慮采用關系型數據庫和Nosql混用的方案。

緩存

當并發的請求到達一定程度，瓶頸大部分情況下發生在DB層面，甚至DB無論怎么優化總有上限。為了避免頻繁查詢數據庫產生瓶頸，誕生了緩存。在訪問數據庫之前加入了緩存層，當然這里的緩存采用的方案在數據的響應時間上要比數據庫小很多，比如常用的redis，Memcache，但是這些第三方的緩存組件還是要走網絡，比起進程內的緩存還是要慢的多。

現在一般流行的設計在網站層和服務層都有緩存策略，只不過緩存的數據和策略有所不同，但是最終目的都是為了加快請求的響應。當然加了緩存之后，數據的一致性需要仔細設計才可以，如果發生數據不一致的情況，程序員可能要背鍋了。

緩解數據庫壓力并不是引入緩存的唯一因素。

CDN加速

一些小廠可能用不到cdn，但是cdn帶來的加速還是很客觀的。cdn依靠部署在各地的邊緣服務器，通過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。CDN就是把離用戶最近的數據返回給用戶。

寫在最后

程序異步化其實并不能縮短響應時間，但是對提高吞吐量有很大作用。

---

本文的重點是你有沒有收獲與成長，其余的都不重要，希望讀者們能謹記這一點。同時我經過多年的收藏目前也算收集到了一套完整的學習資料，包括但不限于：分布式架構、高可擴展、高性能、高并發、Jvm性能調優、Spring，MyBatis，Nginx源碼分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多個知識點高級進階干貨，希望對想成為架構師的朋友有一定的參考和幫助

需要以下資料的可以加一下三千人Java技術交流分享群：“708 701 457”免費獲取

另外有需要云服務器可以了解下創新互聯scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

網站題目：高并發下如何縮短響應時間-創新互聯
鏈接URL：http://www.yijiale78.com/article18/csppdp.html

成都網站建設公司_創新互聯，為您提供外貿建站、網站收錄、網站制作、網站策劃、App設計、網站改版

廣告

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