1、高併發中一些概念
1.pv(訪問量)：頁面訪問量，頁面重新整理一次算一次。
2. uv(獨立訪客)：即unique visitor，乙個客戶端（電腦，手機）為乙個訪客；
3. dau(日活躍使用者數)：登入或使用了某個產品的使用者數，這與流量統計工具裡的訪客（uv）概念相似。
4. 峰值qps：
原理：每天80%的訪問集中在20%的時間裡，這20%時間叫做峰值時間
公式：( 總pv數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(qps)
5.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、說明
1. 由於python中gil的存在，所以為了提高併發通常使用多程序執行web程式，程序數設定為cpu核心數（可以適當多餘cpu數量）
2. 比如我們我們下面的測試環境使用的是，4核 8g的機器，可以設定 uwsgi為： 4個程序，每個程序開2個執行緒
[uwsgi]uwsgi.ini配置socket = 0.0.0.0:3031chdir = /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: 1157000bytes
html transferred: 1119100bytes
requests per second: 154.10 [#
/sec] (mean) # 每秒最多可以處理的請求(qps)
time per request: 194.679 [ms] (mean) #
使用者平均請求等待時間
transfer rate: 1741.15 [kbytes/sec] received #
平均每秒網路上的流量
高併發高負載系統架構
一 為什麼要進行高併發和高負載的研究 1 產品發展的需要 2 公司發展的需要 3 當前形式決定的 二 高併發和高負載的約束條件 1 硬體 2 部署 3 作業系統 4 web 伺服器 5 php 6 mysql 7 測試 三 解決之道 硬體篇 處理能力的提公升 部署多顆cpu，選擇多核心 具備更高運算...
Twitter 高併發高可用架構
解決 twitter的 問題 就像玩玩具一樣，這是乙個很有趣的擴充套件性比喻。每個人都覺得 twitter很簡單，乙個菜鳥架構師隨便擺弄一下個可伸縮的 twitter就有了，就這麼簡單。然而事實不是這樣，twitter的工程副總裁 raffi krikorian細緻深入的描述了在 twitter在可...
高併發高負載系統架構
首先呢，我羅列一下文章的目錄，讓大家有個整體輪廓的了解！1 為什麼要進行高併發和高負載的研究 2 高併發和高負載的約束條件 3 解決之道 硬體篇 4 解決之道 部署篇 5 解決之道 環境篇 6 解決之道 siteengine篇 7 解決之道 測試篇 8 結尾 1 為什麼要進行高併發和高負載的研究 1...