高併發大流量專題---一、高併發大流量解決方案總結

高併發大流量專題---一、高併發大流量解決方案總結

1、總結

一句話總結：

能夠根據 先後端數據庫順序 及 QPS數量來 決定優化方法

 

一、PHP如何解決網站大流量與高併發的問題？

流量優化+前端優化：好比防盜鏈處理、減小HTTP請求、添加異步請求、CDN加速、創建獨立圖片服務器、啓用瀏覽器緩存和文件壓縮等等

服務端優化+Web服務器優化：好比頁面靜態化、併發處理、隊列處理、負載均衡等等

數據庫優化：好比數據庫緩存、分庫分表、分區操做、讀寫分離、負載均衡等等

 

二、咱們說的高併發是什麼？

不是操做系統中的併發：在操做系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行。

某個時間點的併發訪問量：上面的定義明顯不是咱們一般所言的併發，在互聯網時代，所講的併發、高併發，一般是指併發訪問。也就是在某個時間點，有多少個訪問同時到來。

日PV在幹萬以上：一般若是一個系統的日PV在幹萬以上，有多是一個高併發的系統

 

三、高併發解決方案？

技術：各類優化、緩存、負載均衡等技術

機器堆：有的公司徹底不走技術路線，全靠機器堆，有錢，任性

 

四、高併發的問題中，須要瞭解的一些名詞？

qps、吞吐量、響應時間、pv、uv、帶寬、日網站帶寬、峯值

QPS：每秒響應請求數（指HTTP請求）：每秒鐘請求或者查詢的數量，在互聯網領域，指每秒響應請求數（指HTTP請求）；
吞吐量：單位時間內處理的請求數量（一般由QPS與併發數決定）
響應時間：從請求發出到收到響應花費的時間。例如系統處理一個HTTP請求須要100ms，這個100ms就是系統的響應時間
PV：綜合瀏覽量（Page View），即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問的頁面數量；同一我的瀏覽你的網站同一頁面，只記做一次PV
UV：獨立訪客（UniQue Visitor），即必定時間範圍內相同訪客屢次訪問網站，只計算爲1個獨立訪客
帶寬：計算帶寬大小需關注兩個指標，峯值流量和頁面的平均大小
日網站帶寬=PV/統計時間（換算到秒）*平均頁面大小（單位KB）*8
峯值通常是平均值的倍數，根據實際狀況來定
峯值每秒請求數（QPS）=（總PV數*80%）/（6小時秒數*20%）

 

五、日網站帶寬如何計算？

帶寬：計算帶寬大小需關注兩個指標，峯值流量和頁面的平均大小

日網站帶寬=PV/統計時間（換算到秒）*平均頁面大小（單位KB）*8

峯值通常是平均值的倍數，根據實際狀況來定

 

六、QPS 等於併發鏈接數 麼？

不等於：QPS是每秒HTTP請求數量，併發鏈接數是系統同時處理的請求數：一個鏈接裏面可能有多個http請求

 

七、峯值每秒請求數（QPS） 如何計算？

峯值每秒請求數（QPS）=（總PV數*80%）/（6小時秒數*20%）

80%的訪問量集中在20%的時間

 

八、壓力測試是什麼？

最大併發：測試服務器集羣（或單臺）能承受的最大併發

QPS值：測試服務器集羣（或單臺）最大承受的QPS值

通常瞭解單臺服務器可以承受的QPS是多少

 

九、經常使用性能測試工具？

ab、wrk.http load、Web Bench、Siege、Apache JMeter

ab：全稱是apache benchmark，是apache官方推出的工具

ab原理：建立多個併發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的，所以，它既能夠用來測試apache的負載壓力，也能夠測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。

 

十、ab（apache benchmark）是apache官方推出的工具，那麼它可以測試nginx麼？

能：它的測試目標是基於URL的：ab建立多個併發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的，所以，它既能夠用來測試apache的負載壓力，也能夠測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。

 

 

十一、ab的使用（好比 模擬併發請求100次，總共請求5000次）？

運行ab命令：ab -c 100 -n 5000 待測試網站

 

十二、ab測試注意事項？

測試機器與被測試機器分開

不要對線上服務作壓力測試

不超過最高限度的75%：觀察測試工具ab所在機器，以及被測試的前端機的CPU，內存，網絡等都不超過最高限度的75%

 

1三、如何安裝使用ab測試？

獨立安裝：yum -y install httpd-tools

通常安裝apache會自動安裝ab

ab使用：ab -c 100 -n 5000 http://192.168.52.6/index

[root@localhost ~]# ab -c 100 -n 5000 http://192.168.52.6/index
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.52.6 (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        Apache
Server Hostname:        192.168.52.6
Server Port:            80

Document Path:          /index
Document Length:        1917 bytes

Concurrency Level:      100
Time taken for tests:   22.049 seconds
Complete requests:      5000
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      11438133 bytes
HTML transferred:       9579249 bytes
Requests per second:    226.77 [#/sec] (mean)
Time per request:       440.972 [ms] (mean)
Time per request:       4.410 [ms] (mean, across all concurrent requests)
Transfer rate:          506.61 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   9.0      0     125
Processing:     1  419 1614.8     68   17425
Waiting:        0  412 1601.8     68   17425
Total:          1  420 1614.8     72   17427

Percentage of the requests served within a certain time (ms)
  50%     72
  66%    125
  75%    163
  80%    193
  90%    399
  95%    987
  98%   7019
  99%   9085
 100%  17427 (longest request)

 

 

1四、不一樣QPS下，優化與哪些方面有關？

硬件條件

網絡帶寬

隨着QPS的增加，每一個階段須要根據實際狀況來進行優化，優化的方案也與硬件條件、網絡帶寬息息相關。

 

1五、不一樣QPS下的優化方案？

QPS100：數據庫緩存層、數據庫的負載均衡

QPS800：CDN加速、負載均衡

QPS1000：靜態HTML緩存

QPS2000：作業務分離，分佈式存儲

 

1六、QPS達到50 須要優化麼？

能夠不須要；稱之爲小型網站，通常的服務器就能夠應付

 

1七、QPS達到100 如何優化？

|||-begin

假設關係型數據庫的每次請求在0.01秒完成；

假設單頁面只有一個SQL查詢，那麼100QPS意味着1秒鐘完成100次請求，可是此時咱們並不能保證數據庫查詢能完成100次

|||-end

數據庫緩存層、數據庫的負載均衡

 

1八、QPS 達到800 如何優化？

|||-begin

假設咱們使用百兆帶寬，意味着網站出口的實際帶寬是8M左右

假設每一個頁面只有10K，在這個併發條件下，百兆帶寬已經吃完

|||-end

CDN加速、負載均衡

 

1九、QPS 達到1000 如何優化？

|||-begin

假設使用Memcache緩存數據庫查詢數據，每一個頁面對Memcache的請求遠大於直接對DB的請求

Memcache的悲觀併發數在2w左右，但有可能在以前內網帶寬已經吃光，表現出不穩定

|||-end

靜態HTML緩存

 

20、QPS 達到2000 如何優化？

|||-begin

這個級別下，文件系統訪問鎖都成爲了災難

|||-end

作業務分離，分佈式存儲

 

 

2一、高併發優化的方向有哪些？

流量優化+前端優化：好比防盜鏈處理、減小HTTP請求、添加異步請求、CDN加速、創建獨立圖片服務器、啓用瀏覽器緩存和文件壓縮等等

服務端優化+Web服務器優化：好比頁面靜態化、併發處理、隊列處理、負載均衡等等

數據庫優化：好比數據庫緩存、分庫分表、分區操做、讀寫分離、負載均衡等等

流量優化 方法
防盜鏈處理


前端優化 方法
減小HTTP請求
添加異步請求：好比ajax
啓用瀏覽器緩存和文件壓縮
CDN加速
創建獨立圖片服務器



服務端優化 方法
頁面靜態化
併發處理
隊列處理


數據庫優化 方法
數據庫緩存
分庫分表、分區操做
讀寫分離
負載均衡


Web服務器優化 方法
負載均衡

 

2二、流量優化 方法？

防盜鏈處理

 

2三、前端優化 方法？

減小HTTP請求

添加異步請求：好比ajax

啓用瀏覽器緩存和文件壓縮

CDN加速 + 創建獨立圖片服務器

 

2四、服務端優化 方法？

頁面靜態化

併發處理

隊列處理

 

2五、數據庫優化 方法？

數據庫緩存

分庫分表、分區操做

讀寫分離

負載均衡

 

2六、Web服務器優化 方法？

負載均衡

 

2七、如何查看頁面的響應時間？

chrome瀏覽器->network->右下角紅色字：好比 Load:1.65s

 

95 requests I 409 KB transferred I 718 KB resources l Finish:3.06s l DOMContentloaded:910 ms I Load:1.65s

 

 

 

2、內容在總結中