1.1高並發介紹
1、高並發中一些概念
-
1. PV(訪問量)： 頁面訪問量，頁面刷新一次算一次。
-
2. UV(獨立訪客)： 即Unique Visitor，一個客戶端（電腦，手機）為一個訪客；
-
3. DAU(日活躍用戶數)：登錄或使用了某個產品的用戶數，這與流量統計工具里的訪客（UV）概念相似。
-
4.峰值QPS：
原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間
公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
-
- QPS/TPS(每秒查詢率)：每秒能夠查詢次數（QPS/TPS= 並發數 / 平均響應時間）
並發數：並發數是指系統同時能處理的請求數量，這個也是反應了系統的負載能力。
吐吞量：吞吐量是指系統在單位時間內處理請求的數量
響應時間（RT）：響應時間是指系統對請求作出響應的時間，一般取平均響應時間
2、舉例說明
- 1）例1：
1. 假設1秒鍾100個請求，處理每個請求需要花2秒，
2. 那么 50（每秒可以處理50個請求，即QPS使50） = 100（每秒並發數） / 2 （每個請求的平均處理時間）
3. 這是一台機器的QPS，如有每秒並發數為1000，那么就需要10台這樣的機器才扛得住:
- 2）例2：
1. 每天200萬PV，那么它的QPS = （2000000 * 0.8）/ （24*60*60*0.2）≈ 93
2. 假設按照上面那樣一台機器的QPS是50，那么抗住每天200萬PV的訪問量需要2台這樣的機器
3、django性能
-
1）原生django：
用原生django的server做處理的，在10000次請求的情況下brokenpipe的幾率極高，成功率只有14%。 -
2）uwsgi + nginx：
uwsgi是性能極高的一個由C編寫的服務器，它使用uwsgi協議
這次讓它配合nginx處理django的request，參數為4進程+2線程，性能立即直線上升，處理請求的成功率也基本在90%左右
1.2 django + uwsgi性能測試
1、說明
1. 由於Python中GIL的存在，所以為了提高並發通常使用多進程運行web程序，進程數設置為CPU核心數（可以適當多余CPU數量）
2. 比如我們我們下面的測試環境使用的是，4核 8G的機器，可以設置 uwsgi為： 4個進程，每個進程開2個線程
# uwsgi.ini配置
[uwsgi]
socket = 0.0.0.0:3031
chdir = /code
wsgi-file = /code/demo2/wsgi.py
processes = 4 # 開啟5個進程
threads = 2 # 每個進程最多開啟2個線程
master = true
daemonize = /code/uwsgi.log
pidfile = /code/uwsgi.pid
2、我們分別使用在2個、4個、8個並發的情況下的響應時間和QPS
1. 通過下面測試，在並發為4的時候就達到了QPS的最高值，此時再繼續增大並發，只會增加單個http請求的響應時間。
2. 我們在保證響應時間在200ms的情況，通過上面的數據，估計最高並發大約為30
3. 以后在設置uwsgi參數時，將process設置為CPU的核心數就可以了，如果涉及到從磁盤讀取數據的情況，可以考慮加上線程。
4. 如果想增大並發能力就要辦法降低單個http請求的響應時間。
# 注：通過測試可以得出，django+uwsgi在4核機器中QPS最大也很難超過 200
Concurrency Level: 30 # 模擬三十個並發客戶端來壓測
Time taken for tests: 0.649 seconds # 整個測試持續的時間
Complete requests: 100 # 所有請求成功數量
Failed requests: 0
Total transferred: 1157000 bytes
HTML transferred: 1119100 bytes
Requests per second: 154.10 [#/sec] (mean) # 每秒最多可以處理的請求(QPS)
Time per request: 194.679 [ms] (mean) # 用戶平均請求等待時間
Transfer rate: 1741.15 [Kbytes/sec] received # 平均每秒網絡上的流量