ab,qps,服務器性能壓力
"ab,qps,服務器性能壓力"：關鍵詞：ab qps 服務器 性能 壓力
http://www.makaidong.com/program/641799.html
轉載：並發用戶數和qps兩個概念沒有直接關系
轉自: http://blog.hummingbird-one.com/?p=10029
關 於並發用戶數和qps，自己一直被這兩個概念糾結，閱讀了一下相關資料，總結如下：並發用戶數和qps兩個概念沒有直接關系，但是如果要說qps時，一定 需要指明是多少並發用戶數下的qps，否則豪無意義，因為單用戶數的40qps和20並發用戶數下的40qps是兩個不同的概念。前者說明該應用可以在一 秒內串行執行40個請求，而后者說明在並發20個請求的情況下，一秒內該應用能處理40個請求
http://www.tuicool.com/articles/zbafyf
並發連接數 = pv / 統計時間 * 頁面衍生連接次數 * http響應時間 * 因數 / 其他web服務器 數量
pv = 並發連接數 * 統計時間 * 其他web服務器 數量/ 頁面衍生連接次數 / http響應時間 / 因數
解釋： 統計時間 : pv統計的總時間，單位秒，要計算一天的pv就是86400秒 頁面衍生連接次數: 一個html頁面可能會請求好幾次http連接，如外部的css, js ,圖片等,可以估算一下，或者用10,可根據實際情況改變 http響應時間: 可以使用1秒或更少,可根據實際情況改變 因數: 一般使用5即可,可根據實際情況計算后推出 其他web服務器 數量: 其他web服務器 數量
* “頁面衍生連接次數”，”http響應時間”，”因數”這三個參數要根據實際情況分析計算后，確定一個適合的值
推算一下。單台機器1000並發的情況下，一天是1,728,000的pv(1秒響應，10個衍生連接，因子為5的情況下) ======================================================================
例子：
保證每天多少pv的並發連接數的計算公式是： 並發連接數＝ pv / 統計時間(一天是86400) * 頁面衍生連接次數 * http響應時間 * 因數(5) / 其他web服務器 數量
保證4千萬pv的並發連接數： (40000000pv / 86400秒 * 10個派生連接數 * 5秒內響應 * 5倍峰值) / 6台其他web服務器 = 19290連接數
======================================================================
面試時，面試官問道：1億個pv，如何確定並發用戶數？ 一時想不起來具體的公式，就記得80/20原則，就回答了一些。又說了一些原來我們公司會提供峰值的方法，確定最后施壓的用戶數。 今天上網查相關資料，發現一些有用的內容，抄錄下來。
網站流量是指什么? ip和pv呢？ 通常說的網站流量（traffic）是指網站的訪問量，是用來描述訪問一個網站的用戶數量以及用戶所瀏覽的網頁數量等指標，常用的統計指標包括網站的獨立用戶數量、總用戶數量（含重復訪問者）、網頁瀏覽數量、每個用戶的頁面瀏覽數量、用戶在網站的平均停留時間等。
網 站訪問統計分析的基礎是獲取網站流量的基本數據，根據網上營銷新觀察的相關文章，網站流量統計指標大致可以分為三類，每類包含若干數量的統計指標。具體的 網站流量統計是通過不同的ip登陸網站來計算的，也就是說。一天內同一台機器登陸網站的次數不論是多少，在流量統計中只記為一次有效登陸，這種計算方法可 以較為科學 的計算出有多少人登陸過該網站，有效的防止了有意的對網站進行刷新從而增加自己網站的點擊率。
網站流量指標
網站流量統計指標常用來對網站效果進行評價，主要指標包括： ·獨立訪問者數量（unique visitors）； ·重復訪問者數量（repeat visitors） ·頁面瀏覽數（page views）； ·每個訪問者的頁面瀏覽數（page views per user）； ·某些具體文件/頁面的統計指標，如頁面顯示次數、文件下載次數等。
ip 是使用不同ip上網的人訪問你網站的人數，也就是上面的獨立訪問者數量。 一般來說是24小時同一ip不重復記錄的, 也應該24小時不重復記錄。（其實ip也不一定就是獨立訪問者數量，因為有的用戶是公用一個ip的,但大致上可以認為就是今日的獨立訪問者數量。）
pv 則是上面的頁面瀏覽數，是指這些訪問者一共瀏覽了多少次你網站的頁面，他是會重復記錄的，你點這個網站10個頁面，他就會記錄10次。
所以pv一定是>=ip的，如一個網站今天的流量統計是100ip 200pv就是說今天有大致100個獨立訪問者，一共訪問了200次頁面，平均每個用戶訪問頁面數量是 pv/ip=2 ，一般來說這個數字越大說明網站內容越吸引用戶，但也和網站本身的頁面有關。
吞吐量（tps)＝活動的用戶數/響應時間 活動用戶＝並發用戶*[響應時間/（響應時間+思考時間）] 吞吐量（tps)=並發用戶/（響應時間+思考時間） 由此推出： 並發用戶＝活動用戶+吞吐量*思考時間 並發用戶＝活動用戶*（1+思考時間/響應時間） 並發用戶＝吞吐量*（響應時間+思考時間）
並發連接數與pv的換算公式 oncurrent connections＝pv / seconds *（para connect per a page) * (time to react) * (factor) / (web hosts)
pv = concurrent connections * seconds * (web hosts)/ (para connect per a page)/ (time to react)/ (factor)
concurrent connections：並發連接數
seconds: pv統計的總時間，單位秒，要計算一天的pv就是86400秒
para connect per a page: 頁面衍生連接次數。一個html頁面可能會請求好幾次http連接，如外部的css, js ,圖片等。可以估算一下
，或者用10。可根據實際情況改變
time to react：http響應時間，可以使用1秒或更少。可根據實際情況改變
factor：因數，一般使用5即可。可根據實際情況計算后推出
web hosts：其他web服務器 數量
* para connect per a page，time to react，factor這三個參數要根據實際情況分析計算后，確定一個適合的值
推算一下。單台機器1000並發的情況下，一天是1,728,000的pv(1秒響應，10個衍生連接，因子為5的情況下)
==================================================================================
術語說明： qps = req/sec = 請求數/秒
【qps計算pv和機器的方式】
qps統計方式 [一般使用 http_load 進行統計] qps = 總請求數 / ( 進程總數 * 請求時間 ) qps: 單個進程每秒請求服務器的成功次數
單台服務器每天pv計算 公式1：每天總pv = qps * 3600 * 6 公式2：每天總pv = qps * 3600 * 8
服務器計算 服務器數量 = ceil( 每天總pv / 單台服務器每天總pv )
【峰值qps和機器計算公式】
原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間 公式：( 總pv數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(qps) 機器：峰值時間每秒qps / 單台機器的qps = 需要的機器
問：每天300w pv 的在單台機器上，這台機器需要多少qps？ 答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)
問：如果一台機器的qps是58，需要幾台機器來支持？ 答：139 / 58 = 3
ps: 在實際情況中，會把這個考慮的更多一點，就是把qps再往多了調一調，以防萬
ps：下面是性能測試的主要概念和計算公式，記錄下：
一．系統吞度量要素：
一個系統的吞度量（承壓能力）與request對cpu的消耗、外部接口、io等等緊密關聯。
單個reqeust 對cpu消耗越高，外部系統接口、io影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：qps（tps）、並發數、響應時間
qps（tps）：每秒鍾request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和tps理解混淆）
理解了上面三個要素的意義之后，就能推算出它們之間的關系：
qps（tps）= 並發數/平均響應時間
一個系統吞吐量通常由qps（tps）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
決定系統響應時間要素
我們做項目要排計划，可以多人同時並發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。
系統一次調用的響應時間跟項目計划一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有cpu運算、io、外部系統響應等等組成。
二．系統吞吐量評估：
我們在做系統設計的時候就需要考慮cpu運算、io、外部系統響應因素造成的影響以及對系統性能的初步預估。
而通常境況下，我們面對需求，我們評估出來的出來qps、並發數之外，還有另外一個維度：日pv。
通過觀察系統的訪問日志發現，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和qps我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高tps和日pv，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高tps，然后跟進1的關系，計算出系統最高的日吞吐量。b2b中文和淘寶 面對的客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的tps和pv關系比例也不一樣。
a)淘寶
淘寶 流量圖：
淘寶 的tps和pv之間的關系通常為 最高tps：pv大約為 1 : 11*3600 （相當於按最高tps訪問11個小時，這個是商品詳情的場景，不同的應用場景會有一些不同）
b) b2b中文站
b2b的tps和pv之間的關系不同的系統不同的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關系（09年對offerdetail的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導致。
在淘寶 環境下，假設我們壓力測試出的tps為100，那么這個系統的日吞吐量=100*11*3600=396萬
這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。
無論有無思考時間（t_think），測試所得的tps值和並發虛擬用戶數(u_concurrent)、loadrunner讀取的交易響應時間（t_response）之間有以下關系（穩定運行情況下）：
tps=u_concurrent / (t_response+t_think)。
並發數、qps、平均響應時間三者之間關系
來源：http://www.makaidong.com/jackei/
軟件其他 性能測試的基本概念和計算公式
一、軟件其他 性能的關注點
我們想想在軟件其他 設計、部署、使用、維護中一共有哪些角色的參與，然后再考慮這些角
此文來自: 馬開東博客 轉載請注明出處 網址： http://www.makaidong.com
色各自關注的性能點是什么，作為一個軟件其他 性能測試工程師，我們又該關注什么？
首先，開發軟件其他 的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關注哪些性能。
對於用戶來說，當點擊一個按鈕、鏈接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來為止，這個過程所消耗的時間是用戶對這個軟件其他 性能的直觀印象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗 是很好的，當然用戶體驗 的響應時間包括個人主觀因素和客觀響應時間，在設計軟件其他 時，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以將先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢索，這時用戶並不知道我們后台在做什么。
用戶關注的是用戶操作的相應時間。
其次，我們站在管理員的角度考慮需要關注的性能點。
1、 相應時間
2、 服務器資源使用情況是否合理
3、 應用服務器 和其他數據庫 資源使用是否合理
4、 系統能否實現擴展
5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
6、 系統性能可能存在的瓶頸在哪里
7、 更換那些設備可以提其他高性能
8、 系統能否支持7×24小時的業務訪問
再次，站在開發（設計）人員角度去考慮。
1、 架構設計是否合理
2、 其他數據庫 設計是否合理
3、 代碼是否存在性能方面的問題
4、 系統中是否有不合理的內存使用方式
5、 系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競爭
那么站在性能測試工程師的角度，我們要關注什么呢？
一句話，我們要關注以上所有的性能點。
二、軟件其他 性能的幾個主要術語
1、響應時間：對請求作出響應所需要的時間
網絡傳輸時間：n1+n2+n3+n4
應用服務器 處理時間：a1+a3
其他數據庫 服務器處理時間：a2
響應時間=n1+n2+n3+n4+a1+a3+a2
2、並發用戶數的計算公式
系統用戶數：系統額定的用戶數量，如一個oa系統，可能使用該系統的用戶總數是5000個，那么這個數量，就是系統用戶數。
同時在線用戶數：在一定的時間范圍內，最大的同時在線用戶數量。
同時在線用戶數=每秒請求數rps（吞吐量）+並發連接數+平均用戶思考時間
平均並發用戶數的計算：c=nl / t
其中c是平均的並發用戶數，n是平均每天訪問用戶數（login session），l是一天內用戶從登錄到退出的平均時間（login session的平均時間），t是考察時間長度（一天內多長時間有用戶使用系統）
並發用戶數峰值計算：c^約等於c + 3*根號c
其中c^是並發用戶峰值，c是平均並發用戶數，該公式遵循泊松分布理論。
3、吞吐量的計算公式
指單位時間內系統處理用戶的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量
從網絡角度看，吞吐量可以用：字節/秒來衡量
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力
以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器 制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器 和應用代碼的制約體現出的瓶頸。
當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：f=vu * r /
其中f為吞吐量，vu表示虛擬用戶個數，r表示每個虛擬用戶發出的請求數，t表示性能測試所用的時間
4、性能計數器
是描述服務器或操作系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮着“監控和分析”的作用，尤其是在分析統統可擴展性、進行新能瓶頸定位時有着非常關鍵的作用。
資源利用率：指系統各種資源的使用情況，如cpu占用率為68%，內存占用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源利用率。
5、思考時間的計算公式
think time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。
在吞吐量這個公式中f=vu * r / t說明吞吐量f是vu數量、每個用戶發出的請求數r和時間t的函數，而其中的r又可以用時間t和用戶思考時間ts來計算：r = t / ts
下面給出一個計算思考時間的一般步驟：
a、首先計算出系統的並發用戶數
c=nl / t f=r×c
b、統計出系統平均的吞吐量
f=vu * r / t r×c = vu * r / t
c、統計出平均每個用戶發出的請求數量
r=u*c*t/vu
d、根據公式計算出思考時間
ts=t/r
http://www.vpser.net/opt/webserver-test.html
一、http_load
程序非常小，解壓后也不到100k
http_load以並行復用的方式運行，用以測試其他web服務器 的吞吐量與負載。但是它不同於大多數壓力測試工
具，它可以以一個單一的進程運行，一般不會把客戶機搞死。還可以測試https類的網站請求。
下 載地址：http://soft.vpser.net/test/http_load/http_load-12mar2006.tar.gz 安裝很簡單 #tar zxvf http_load-12mar2006.tar.gz #cd http_load-12mar2006 #make && make install
命令格式：http_load -p 並發訪問進程數 -s 訪問時間 需要訪問的url文件
參數其實可以自由組合，參數之間的選擇並沒有什么限制。比如你寫成http_load -parallel 5 -seconds
300 urls.txt也是可以的。我們把參數給大家簡單說明一下。 -parallel 簡寫-p ：含義是並發的用戶進程數。 -fetches 簡寫-f ：含義是總計的訪問次數 -rate 簡寫-p ：含義是每秒的訪問頻率 -seconds簡寫-s ：含義是總計的訪問時間
准備url文件：urllist.txt，文件格式是每行一個url，url最好超過50－100個測試效果比較好.文件格式
如 下： http://www.vpser.net/uncategorized/choose-vps.html http://www.vpser.net/vps-cp/hypervm-tutorial.html http://www.vpser.net/coupons/diavps-april-coupons.html http://www.vpser.net/security/vps-backup-web-mysql.html 例如：
http_load -p 30 -s 60 urllist.txt 參數了解了，我們來看運行一條命令來看看它的返回結果 命令：% ./http_load -rate 5 -seconds 10 urls說明執行了一個持續時間10秒的測試，每秒的頻率為5。
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274
fetches/sec, 28945.5 bytes/secms ecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first
-response: 63.5362 mean, 81.624 max, 57.803 minhttp response codes: code 200 -- 49
結 果分析： 1．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 說明在上面的測試中運行了49個請求，最大的並發進程數是2，總計傳輸的數據是289884bytes，運行的時間是10.0148秒 2．5916 mean bytes/connection說明每一連接平均傳輸的數據量289884/49=5916 3．4.89274 fetches/sec, 28945.5 bytes/sec 說明每秒的響應請求為4.89274，每秒傳遞的數據為28945.5 bytes/sec 4．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min說明每連接的平均響應時間是28.8932 msecs
， 最大的響應時間44.243 msecs，最小的響應時間24.488 msecs 5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min 6、http response codes: code 200 -- 49 說明打開響應頁面的類型，如果403的類型過多，那可能
要注意是否系統遇到了瓶頸。 特殊說明： 測試結果中主要的指標是 fetches/sec、msecs/connect 這個選項，即服務器每秒能夠響應的查詢次數，
用這個指標來衡量性能。似乎比 apache的ab准確率要高一些，也更有說服力一些。 qpt-每秒響應用戶數和response time，每連接響應用戶時間。 測試的結果主要也是看這兩個值。當然僅有這兩個指標並不能完成對性能的分析，我們還需要對服務器的
cpu、men進行分析，才能得出結論
二、webbench
webbench是linux下的一個網站壓力測試工具，最多可以模擬3萬個並發連接去測試網站的負載能力。下載
地 址可以到google搜，我這里給出一個 下載地址：http://soft.vpser.net/test/webbench/webbench-1.5.tar.gz 這個程序更小，解壓后不到50k，呵呵 安裝非常簡單 #tar zxvf webbench-1.5.tar.gz #cd webbench-1.5 #make && make install 會在當前目錄生成webbench可執行文件，直接可以使用了
用法：
webbench -c 並發數 -t 運行測試時間 url 如： webbench -c 5000 -t 120 http://www.vpser.net/
三、ab ab是apache自帶的一款功能強大的測試工具 安裝了apache一般就自帶了， 用法可以查看它的說明
$ ./ab ./ab: wrong number of arguments usage: ./ab [options] [http://]hostname[:port]/path options are: -n requests number of requests to perform -c concurrency number of multiple requests to make -t timelimit seconds to max. wait for responses -p postfile file containing data to post -t content-type content-type header for posting -v verbosity how much troubleshooting info to print -w print out results in html tables -i use head instead of get -x attributes string to insert as table attributes -y attributes string to insert as tr attributes -z attributes string to insert as td or th attributes -c attribute add cookie, eg. 'apache=1234. (repeatable) -h attribute add arbitrary header line, eg. 'accept-encoding: gzip' inserted after all normal header lines. (repeatable) -a attribute add basic www authentication, the attributes are a colon separated username and password . -p attribute add basic proxy authentication, the attributes are a colon separated username and password . -x proxy:port proxyserver and port number to use -v print version number and exit -k use http keepalive feature -d do not show percentiles served table. -s do not show confidence estimators and warnings. -g filename output collected data to gnuplot format file. -e filename output csv file with percentages served -h display usage information (this message) 參數眾多，一般我們用到的是-n 和-c 例如： ./ab -c 1000 -n 100 http://www.vpser.net/index.php
這個表示同時處理1000個請求並運行100次index.php文件. 四、siege 一款開源的壓力測試工 具，可以根據配置對一個web站點進行多用戶的並發訪問，記錄每個用戶所有請求過程的相應時間，並在一定數量的並發訪問下重復進行。 官方：http://www.joedog.org/ siege下載：http://soft.vpser.net/test/siege/siege-2.67.tar.gz 解壓： # tar -zxf siege-2.67.tar.gz 進入解壓目錄： # cd siege-2.67/ 安裝： #./configure ; make #make install
使用 siege -c 200 -r 10 -f example.url -c是並發量，-r是重復次數。 url文件就是一個文本，每行都是一個url，它會從里面隨機訪問的。
example.url內容:
http://www.licess.cn http://www.vpser.net http://soft.vpser.net
結 果說明 lifting the server siege… done. transactions: 3419263 hits //完成419263次處理 availability: 100.00 % //100.00 % 成功率 elapsed time: 5999.69 secs //總共用時 data transferred: 84273.91 mb //共數據傳輸84273.91 mb response time: 0.37 secs //相應用時1.65秒：顯示網絡連接的速度 transaction rate: 569.91 trans/sec //均每秒完成 569.91 次處理：表示服務器后 throughput: 14.05 mb/sec //平均每秒傳送數據 concurrency: 213.42 //實際最高並發數 successful transactions: 2564081 //成功處理次數 failed transactions: 11 //失敗處理次數 longest transaction: 29.04 //每次傳輸所花最長時間 shortest transaction: 0.00 //每次傳輸所花最短時間
>>轉載請注明出處：vps偵探 本文鏈接地址：http://www.vpser.net/opt/webserver-test.html
http://www.sphinxsearch.org/archives/305
在測試站點性能時找到個不錯的說明式文章
from：http://blog.馬開東/lyflower/archive/2010/09/09/5873544.aspx
到http://www.acme.com/software/http_load/ 下載http_load ，安裝也很簡單直接make;make instlall 就行。
http_load 的標准的兩個例子是：
http_load -parallel 5 -fetches 1000 urls.txt http_load -rate 2 -seconds 300 urls.txt 例子只是個參考，參數其實可以自由組合，參數之間的選擇並沒有什么限制。比如你寫成http_load -parallel 5 -seconds 300 urls.txt 也是可以的。我們把參數給大家簡單說明一下。 -parallel 簡寫 -p ： 含義是並發的用戶進程數。
-fetches 簡寫 -f ： 含義是總計的訪問次數
-rate 簡寫 -p ： 含義是每秒的訪問頻率
-seconds 簡寫 -s ： 含義是總計的訪問時間
urls.txt 是一個url 列表，每個url 單獨的一行。當然也可以直接跟一個url 而不是url 列表文件。 實例：
http_load -rate 5 -seconds 10 urls 49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 5916 mean bytes/connection 4.89274 fetches/sec, 28945.5 bytes/sec msecs/connect: 28.8932 mean, 44.243 max, 24.488 min msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min http response codes: code 200 — 49 分析： 1．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 說明在上面的測試中運行了49個請求，最大的並發進程數是2，總計傳輸的數據是289884bytes，運行的時間是10.0148秒
2．5916 mean bytes/connection 說明每一連接平均傳輸的數據量289884/49=5916
3．4.89274 fetches/sec, 28945.5 bytes/sec 說明每秒的響應請求為4.89274，每秒傳遞的數據為28945.5 bytes/sec
4．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min 說明每連接的平均響應時間是28.8932 msecs，最大的響應時間44.243 msecs，最小的響應時間24.488 msecs
5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
6、 http response codes: code 200 — 49 說明打開響應頁面的類型，如果403的類型過多，那可能要注意是否系統遇到了瓶頸。 特殊說明：這里，我們一般會關注到的指標是fetches/sec、msecs/connect 他們分別對應的常用性能指標參數qpt-每秒響應用戶數和response time，每連接響應用戶時間。測試的結果主要也是看這兩個值。當然僅有這兩個指標並不能完成對性能的分析，我們還需要對服務器的cpu、men進行分 析，才能得出結論
sample run:
% ./http_load -rate 5 -seconds 10 urls
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
http response codes:
code 200 — 49
4.89274 fetches/sec 這個值得就是說服務器每秒能夠響應的查詢次數為4.8左右
這個值得是根據 49 fetches /
10.0148 seconds 秒計算出來的
測試網站每秒所能承受的平均訪問量 http_load -parallel 5 -fetches 1000 urls.txt
這段命令行是同時使用5個進程，隨機訪問urls.txt中的網址列表，總共訪問1000次。運行之后的結果：
1000 fetches, 5 max parallel, 6e+06 bytes, in 58.1026 seconds 6000 mean bytes/connection 17.2109 fetches/sec , 103266 bytes/sec msecs/connect: 0.403263 mean, 68.603 max, 0.194 min msecs/first-response: 284.133 mean, 5410.13 max, 55.735 min http response codes: code 200 — 1000
從上面的運行結果來看，目
此文來自: 馬開東博客 轉載請注明出處 網址： http://www.makaidong.com
標網站僅僅能夠承受每秒17次訪問，不夠強壯。
測試網站是否能承受住預期的訪問壓力 http_load -rate 2 -seconds 300 urls.txt
在300秒內保持一定的頻率訪問目標url。
如 果你需要測試https，你必須將 makefile中 # configure: if you want to compile in support for https, uncomment these # definitions. you will need to have already built openssl, available at # http://www.openssl.org/ make sure the ssl_tree definition points to the # tree with your openssl installation – depending on how you installed it, # it may be in /usr/local instead of /usr/local/ssl. ssl_tree = /usr ssl_defs = -duse_ssl ssl_inc = -i$(ssl_tree)/include ssl_libs = -l$(ssl_tree)/lib -lssl -lcrypto
由於使用到openssl，你必須安裝openssl和相應的開發環境
apt-get install openssl apt-get install libssl-dev
find -name ssl.h /usr /include/openssl/ssl.h
所以上面紅色字體部分必須修改
http_load常見問題 平常使用http_load過程中的一些總結，分享出來，大家可以一起補充；
1.提示：bytes count wrong 如果httpd_load獲取到的頁面數據和上次不一致則會報錯byte count wrong 如果是動態頁面,此報錯可以忽略；
2.報錯：too many open files 系統限制的open files太小，ulimit -n 修改open files值即可；
3.無法發送大請求 （請求長度>600個字符） 默認接受請求的buf大小 http_load.c
912 static void 913 handle_connect( int cnum, struct timeval* nowp, int double_check ) 914 { 915 int url_num; 916 char buf[600]; //根據需要修改，如：char buf[4096] 917 int bytes, r;
重新編譯即可得到可發送大請求
4.cannot assign requested address 客戶端頻繁的連服務器，由於每次連接都在很短的時間內結束，導致很多的time_wait，以至於用光了可用的端口號，所以新的連接沒辦法綁定端口，所以 要改客戶端機器的配置， 在sysctl.conf里加：
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將time-wait sockets重新用於新的tcp連接，默認為0，表示關閉； net.ipv4.tcp_timestamps=1 開啟對於tcp時間戳的支持,若該項設置為0，則下面一項設置 不起作用 net.ipv4.tcp_tw_recycle=1 表示開啟tcp連接中time-wait sockets的快速回收 apache ab壓力測試
以前安裝好apache總是不知道該如何測試apache的性能，現在總算找到一個測試工具了。就是apache自帶的測試工具ab(apache benchmark).在apache的bin目錄下。
格 式： ./ab [options] [http://]hostname[:port]/path 參數： -n requests number of requests to perform //在測試會話中所執行的請求個數。默認時，僅執行一個請求 -c concurrency number of multiple requests to make //一次產生的請求個數。默認是一次一個。 -t timelimit seconds to max. wait for responses //測試所進行的最大秒數。其內部隱含值是-n 50000。它可以使對服務器的測試限制在一個固定的總時間以內。默認時，沒有時間限制。 -p postfile file containing data to post //包含了需要post的數據的文件. -t content-type content-type header for posting //post數據所使用的content-type頭信息。 -v verbosity how much troubleshooting info to print //設置顯示信息的詳細程度 – 4或更大值會顯示頭信息， 3或更大值可以顯示響應代碼(404, 200等), 2或更大值可以顯示警告和其他信息。 -v 顯示版本號並退出。 -w print out results in html tables //以html表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。 -i use head instead of get // 執行head請求，而不是get。 -x attributes string to insert as table attributes // -y attributes string to insert as tr attributes // -z attributes string to insert as td or th attributes // -c attribute add cookie, eg. ‘apache=1234. (repeatable) //-c cookie-name=value 對請求附加一個cookie:行。 其典型形式是name=value的一個參數對。此參數可以重復。 -h attribute add arbitrary header line, eg. ‘accept-encoding: gzip’ inserted after all normal header lines. (repeatable) -a attribute add basic www authentication, the attributes are a colon separated username and password . -p attribute add basic proxy authentication, the attributes are a colon separated username and password . //-p proxy-auth-username:password 對一個中轉代理提供basic認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。無論服務器是否需要(即, 是否發送了401認證需求代碼)，此字符串都會被發送。 -x proxy:port proxyserver and port number to use -v print version number and exit -k use http keepalive feature -d do not show percentiles served table. -s do not show confidence estimators and warnings. -g filename output collected data to gnuplot format file. -e filename output csv file with percentages served -h display usage information (this message) //-attributes 設置 屬性的字符串. 缺陷程序中有各種靜態聲明的固定長度的緩沖區。另外，對命令行參數、服務器的響應頭和其他外部輸入的解析也很簡單，這可能會有不良后果。它沒有完整地實現 http/1.x; 僅接受某些’預想’的響應格式。 strstr(3)的頻繁使用可能會帶來性能問題，即, 你可能是在測試ab而不是服務器的性能。
參數很多,一般我們用 -c 和 -n 參數就可以了. 例如:
./ab -c 1000 -n 1000 http://127.0.0.1/index.php
這 個表示同時處理1000個請求並運行1000次index.php文件. #/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312 this is apachebench, version 2.0.41-dev <$revision: 1.121.2.12 $> apache-2.0 copyright (c) 1996 adam twiss, zeus technology ltd, http://www.zeustech.net/ copyright (c) 1998-2002 the apache software foundation, http://www.apache.org/
benchmarking 127.0.0.1 (be patient) completed 100 requests completed 200 requests completed 300 requests completed 400 requests completed 500 requests completed 600 requests completed 700 requests completed 800 requests completed 900 requests finished 1000 requests
server software: apache/2.0.54 // 平台apache 版本2.0.54 server hostname: 127.0.0.1 //服務器主機名 server port: 80 //服務器端口
document path: /index.html.zh-cn.gb2312 //測試的頁面文檔 document length: 1018 bytes //文檔大小
concurrency level: 1000 //並發數 time taken for tests: 8.188731 seconds //整個測試持續的時間 complete requests: 1000 //完成的請求數量 failed requests: 0 //失敗的請求數量 write errors: 0
total transferred: 1361581 bytes //整個場景中的網絡傳輸量 html transferred: 1055666 bytes //整個場景中的html內容傳輸量 requests per second: 122.12 [#/sec] (mean) //大家最關心的指標之一，相當於 lr 中的 每秒事務數 ，后面括號中的 mean 表示這是一個平均值 time per request: 8188.731 [ms] (mean) //大家最關心的指標之二，相當於 lr 中的 平均事務響應時間 ，后面括號中的 mean 表示這是一個平均值 time per request: 8.189 [ms] (mean, across all concurrent requests) //每個請求實際運行時間的平均值 transfer rate: 162.30 [kbytes/sec] received //平均每秒網絡上的流量，可以幫助排除是否存在網絡流量過大導致響應時間延長的問題
connection times (ms) min mean[+/-sd] median max connect: 4 646 1078.7 89 3291 processing: 165 992 493.1 938 4712 waiting: 118 934 480.6 882 4554 total: 813 1638 1338.9 1093 7785 //網絡上消耗的時間的分解，各項數據的具體算法還不是很清楚
percentage of the requests served within a certain time (ms) 50% 1093 66% 1247 75% 1373 80% 1493 90% 4061 95% 4398 98% 5608 99% 7368 100% 7785 (longest request) //整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的用戶響應時間小於1093 毫秒，60％ 的用戶響應時間小於1247 毫秒，最大的響應時間小於7785 毫秒
由於對於並發請求，cpu實際上並不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，所以基本上第一個time per request時間約等於第二個time per request時間乘以並發請求數
3、siege
1)、簡介 一款開源的壓力測試工具，可以根據配置對一個web站點進行多用戶的並發訪問，記錄每個用戶所有請求過 程的相應時間，並在一定數量的並發訪問下重復進行。
2)、獲取
http://www.joedog.org/
3)、 安裝 [root@localhost software]# tar -zxvf siege-2.69.tar.gz #解壓 [root@localhost software]# cd siege-2.69 [root@localhost siege-2.69]# ./configure –prefix=/usr/local/siege #配置安裝目錄 [root@localhost siege-2.69]# make && make install #編譯安裝
注 意：安裝是會提示一下錯誤， make[3]: entering directory `/usr/local/software/siege-2.69/doc’ /usr/bin/install: cannot create regular file `/usr/local/siege/etc/siegerc’: no such file or directory make[3]: *** [install-exec-hook] error 1 make[3]: leaving directory `/usr/local/software/siege-2.69/doc’ make[2]: *** [install-exec-am] error 2 make[2]: leaving directory `/usr/local/software/siege-2.69/doc’ make[1]: *** [install-am] error 2 make[1]: leaving directory `/usr/local/software/siege-2.69/doc’ make: *** [install-recursive] error 1 解決辦法是：mkdir -p /usr/local/siege/etc/siegerc 建立這樣一個目錄就可以繼續向下安裝的。
4)、使用
命令格式：siege -c 並發量 -r 重復次數 -f urllist文件 urllist格式：
http://www.taoav.com
http://www.tuhaoduo.com
http://www.tiaonv.com
結 果說明： lifting the server siege… done. transactions: 3419263 hits //完成419263次處理 availability: 100.00 % //100.00 % 成功率 elapsed time: 5999.69 secs //總共用時 data transferred: 84273.91 mb //共數據傳輸84273.91 mb response time: 0.37 secs //相應用時1.65秒：顯示網絡連接的速度 transaction rate: 569.91 trans/sec //均每秒完成 569.91 次處理：表示服務器后 throughput: 14.05 mb/sec //平均每秒傳送數據 concurrency: 213.42 //實際最高並發數 successful transactions: 2564081 //成功處理次數 failed transactions: 11 //失敗處理次數 longest transaction: 29.04 //每次傳輸所花最長時間 shortest transaction: 0.00 //每次傳輸所花最短時間
本文來自CSDN 博客，轉載請標明出處：http://blog.馬開東/lyflower/archive/2010/09/09/5873544.aspx
http://www.ha97.com/4617.html
ps：網站性能壓力測試是性能調優過程中必不可少的一環。只有讓服務器處在高壓情況下才能真正體現出各種設置所暴露的問題。apache中有個自帶的，名為ab的程序，可以對apache或其它類型的服務器進行網站訪問壓力測試。
apachebench命令原理：
ab命令會創建很多的並發訪問線程，模擬多個訪問者同時對某一url地址進行訪問。它的測試目標是基於url的，因此，既可以用來測試apache的負載壓力，也可以測試nginx、lighthttp、tomcat、iis等其它其他web服務器 的壓力。
ab命令對發出負載的計算機要求很低，既不會占用很高cpu，也不會占用很多內存，但卻會給目標服務器造成巨大的負載，其原理類似cc攻擊。自己測試使用也須注意，否則一次上太多的負載，可能造成目標服務器因資源耗完，嚴重時甚至導致死機。
apachebench參數說明
格式：ab [options] [http://]hostname[:port]/path
參數說明：
-n requests number of requests to perform
//在測試會話中所執行的請求個數（本次測試總共要訪問頁面的次數）。默認時，僅執行一個請求。
-c concurrency number of multiple requests to make
//一次產生的請求個數（並發數）。默認是一次一個。
-t timelimit seconds to max. wait for responses
//測試所進行的最大秒數。其內部隱含值是-n 50000。它可以使對服務器的測試限制在一個固定的總時間以內。默認時，沒有時間限制。
-p postfile file containing data to post
//包含了需要post的數據的文件，文件格式如“p1=1&p2=2”.使用方法是 -p 111.txt 。 （配合-t）
-t content-type content-type header for posting
//post數據所使用的content-type頭信息，如 -t “application/x-www-form-urlencoded” 。 （配合-p）
-v verbosity how much troubleshooting info to print
//設置顯示信息的詳細程度 – 4或更大值會顯示頭信息， 3或更大值可以顯示響應代碼(404, 200等), 2或更大值可以顯示警告和其他信息。 -v 顯示版本號並退出。
-w print out results in html tables
//以html表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。
-i use head instead of get
// 執行head請求，而不是get。
-x attributes string to insert as table attributes
-y attributes string to insert as tr attributes
-z attributes string to insert as td or th attributes
-c attribute add cookie, eg. -c “c1=1234,c2=2,c3=3′ (repeatable)
//-c cookie-name=value 對請求附加一個cookie:行。 其典型形式是name=value的一個參數對。此參數可以重復，用逗號分割。
提示：可以借助session實現原理傳遞 js essionid參數， 實現保持會話的功能，如
-c ” c1=1234,c2=2,c3=3, js essionid=ff056cd16da9d71cb131c1d56f0319f8′ 。
-h attribute add arbitrary header line, eg. ‘accept-encoding: gzip’ inserted after all normal header lines. (repeatable)
-a attribute add basic www authentication, the attributes
are a colon separated username and password .
-p attribute add basic proxy authentication, the attributes
are a colon separated username and password .
//-p proxy-auth-username:password 對一個中轉代理提供basic認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。無論服務器是否需要(即, 是否發送了401認證需求代碼)，此字符串都會被發送。
-x proxy:port proxyserver and port number to use
-v print version number and exit
-k use http keepalive feature
-d do not show percentiles served table.
-s do not show confidence estimators and warnings.
-g filename output collected data to gnuplot format file.
-e filename output csv file with percentages served
-h display usage information (this message)
//-attributes 設置屬性的字符串. 缺陷程序中有各種靜態聲明的固定長度的緩沖區。另外，對命令行參數、服務器的響應頭和其他外部輸入的解析也很簡單，這可能會有不良后果。它沒有完整地實現 http/1.x; 僅接受某些’預想’的響應格式。 strstr(3)的頻繁使用可能會帶來性能問題，即你可能是在測試ab而不是服務器的性能。參數很多，一般我們用 -c 和 -n 參數就可以了。例如:
# ab -c 5000 -n 600 http://127.0.0.1/index.php
apachebench用法詳解：
在linux系統，一般安裝好apache后可以直接執行；# ab -n 4000 -c 1000 http://www.ha97.com/
如果是win系統下，打開cmd命令行窗口，cd到apache安裝目錄的bin目錄下；
-n后面的4000代表總共發出4000個請求；-c后面的1000表示采用1000個並發（模擬1000個人同時訪問），后面的網址表示測試的目標url。
稍等一會得到類似如下顯示結果：
結果分析：
this is apachebench, version 2.3
copyright 1996 adam twiss, zeus technology ltd, http://www.zeustech.net/
licensed to the apache software foundation, http://www.apache.org/benchmarking 192.168.80.157 (be patient)
completed 400 requests
completed 800 requests
completed 1200 requests
completed 1600 requests
completed 2000 requests
completed 2400 requests
completed 2800 requests
completed 3200 requests
completed 3600 requests
completed 4000 requests
finished 4000 requestsserver software: apache/2.2.15
server hostname: 192.168.80.157
server port: 80document path: /phpinfo.php
#測試的頁面
document length: 50797 bytes
#頁面大小concurrency level: 1000
#測試的並發數
time taken for tests: 11.846 seconds
#整個測試持續的時間
complete requests: 4000
#完成的請求數量
failed requests: 0
#失敗的請求數量
write errors: 0
total transferred: 204586997 bytes
#整個過程中的網絡傳輸量
html transferred: 203479961 bytes
#整個過程中的html內容傳輸量
requests per second: 337.67 [#/sec] (mean)
#最重要的指標之一，相當於lr中的每秒事務數，后面括號中的mean表示這是一個平均值
time per request: 2961.449 [ms] (mean)
#最重要的指標之二，相當於lr中的平均事務響應時間，后面括號中的mean表示這是一個平均值
time per request: 2.961 [ms] (mean, across all concurrent requests)
#每個連接請求實際運行時間的平均值
transfer rate: 16866.07 [kbytes/sec] received
#平均每秒網絡上的流量，可以幫助排除是否存在網絡流量過大導致響應時間延長的問題
connection times (ms)
min mean[+/-sd] median max
connect: 0 483 1773.5 11 9052
processing: 2 556 1459.1 255 11763
waiting: 1 515 1459.8 220 11756
total: 139 1039 2296.6 275 11843
#網絡上消耗的時間的分解，各項數據的具體算法還不是很清楚percentage of the requests served within a certain time (ms)
50% 275
66% 298
75% 328
80% 373
90% 3260
95% 9075
98% 9267
99% 11713
100% 11843 (longest request)
# 整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的用戶響應時間小於275毫秒，66％的用戶響應時間小於298毫秒，最大 的響應時間小於11843毫秒。對於並發請求，cpu實際上並不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，所以基本上第一個time per request時間約等於第二個time per request時間乘以並發請求數。
總結：在遠程對其他web服務器 進行壓力測試，往往效果不理想（因為網絡延時過大），建議使用內網的另一台或者多台服務器通過內網進行測試，這樣得出的數據，准確度會高很多。如果只有單獨的一台服務器，可以直接本地測試，比遠程測試效果要准確。
############################################################
http://www.blogjava.net/neverend/archive/2011/01/25/343514.html
術語說明： qps = req/sec = 請求數/秒
【qps計算pv和機器的方式】
qps統計方式 [一般使用 http_load 進行統計] qps = 總請求數 / ( 進程總數 * 請求時間 ) qps: 單個進程每秒請求服務器的成功次數
單台服務器每天pv計算 公式1：每天總pv = qps * 3600 * 6 公式2：每天總pv = qps * 3600 * 8
服務器計算 服務器數量 = ceil( 每天總pv / 單台服務器每天總pv )
【峰值qps和機器計算公式】
原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間 公式：( 總pv數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(qps) 機器：峰值時間每秒qps / 單台機器的qps = 需要的機器
問：每天300w pv 的在單台機器上，這台機器需要多少qps？ 答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)
問：如果一台機器的qps是58，需要幾台機器來支持？ 答：139 / 58 = 3
http://blog.hummingbird-one.com/?tag=web-%e6%80%a7%e8%83%bd-qps-%e7%ad%89%e5%be%85%e6%97%b6%e9%97%b4
http://jjw.javaeye.com/blog/703864
##########################################################################
http://www.makaidong.com/yjf512/archive/2013/03/22/2974842.html
從事服務端開發已經有一些日子了，靜下來可以想想和記錄些服務端開發的想法了。
服 務端開發，特別是web開發，基本上全是處理http請求的處理。根據具體用途分為兩種：web頁面開發和api接口開發。web頁面開發也完全可以看成 是api接口開發，只是它的兩個主要部分，頁面和ajax請求，一個是返回html，另外一個可以返回html，也可以返回其他格式的而已。api接口開 發是針對有客戶端產品而言的。可能是移動設備，可能是pc應用等。
應用框架
應用框架一般使用的是lnmp或者lamp，基本的框架就是前端n台web服務機 + cgi訪問php + php訪問mysql。
php可以看成是c寫的一個大型的web框架，它的優勢在於解釋型，即時修改即時更新。所以線上代碼更新維護成本極低，加之其為web開發幾乎是專門定制的一些函數，所以適合用於web開發。相較於java開發web服務，動不動就需要重新編譯的痛苦就很知足了。
其他web服務器 現在nginx是越來越多使用，nginx比較apache的優勢就在於輕便和靜態頁面的高並發性能。一般拿到設備先需要考慮下單機可承受的qps大概多 少，方法大致就是先只考慮內存，計算同時能開啟多少個php-cgi，比如一個4g內存的機器，每個php-fpm大概占用20m內存，所以差不多能開啟 200個php-cgi進程（一般會留些空余的），每個進程同一個時間只能跑一個php程序，所以假設每個php程序跑0.1s，1s就能處理10個請 求，所以單機qps大概會是2000。當然，一般不會開啟到這么極致的程度，有幾個原因：
1 需要考慮到其他進程使用內存的情況
2 考慮到如果一旦全部內存都使用完了，是否啟用swap，如果沒有的話，那機器是否就立即當機
3 還需要考慮到cpu和帶寬的使用情況。cpu對一些比如加解密，視頻轉碼等操作比較耗時，這個時候如果沒有使用隊列，那么每個請求的時間就會加長。
文件服務器
一般會要求文件服務器和其他web服務器 分開，分開的意思就是使用不同的域名進行拆分。當然其他web服務器 也是可以當做文件服務器的，但是由於文件服務器需要上傳文件，而上傳文件是一個非常耗時的工作，即php的一個程序需要停留的時間很長，所以需要將它們分開。一則可以為以后擴展文件服務器提供便利，二則不會導致文件服務影響了正常的web服務。
從文件服務器拆分的理由上看，在運營過程中一些比較占用資源或者特別頻繁調用的接口是可以或者應該考慮拆分到不同機器上的。
web前端機始終要訪問持久化的數據的，mysql的使用是最為頻繁的。其實所有的web服務說到底都是對其他數據庫 進行增刪改查的操作。說到性能，其他數據庫 的增刪改查操作的性能其實就決定了一切。所以對其他數據庫 的建表，索引的使用對一個網站來說尤為重要。覺得最有用的幾個mysql的技巧有：
1 覆蓋索引。就是想辦法讓查詢操作只查索引而不去查表的索引建立方法。建立合適的索引和能只在索引就能找到數據的查詢能提高效率。
2 innodb表最好能使用自增鍵，提高插入操作的效率。
3 string類型的變量的存儲格式，是使用varchar還是char比較好，曾經有個項目表設計從char到varchar之后的其他數據庫 大小差別達到70g和20g的大小…
4 建表的時候需要考慮下以后的分庫分表，如果是使用分表，什么是分表鍵？是否需要反向查詢表？
5 甚至當考慮到其他數據庫 和web機器的機房分布，這個設計就更麻煩了...
mysql的建表環節和需求有很大關系。沒有明確的需求，表設計一定是不正確的。
其他數據庫 支持有可能還是不足夠的，那么首先想到的可能就是緩存了。緩存是使用全局緩存？放在web前端機？需要用什么hash算法？用什么緩 存？memcache？redis？mysql也有自帶緩存，如何查詢才能更好命中這個緩存？當數據更新的時候，緩存中的數據是否是臟數據？如何更新數 據？
web頁面開發
當需要做一個網站的時候，首先要考慮的是用戶量有多少？做一個sns網站和做一個運營后台網站完全是兩個不同的概念。
首先是在頁面壓力上，sns網站的qps可能幾千上萬，而運營后台壓力幾乎完全可以不用計算。這個就意味着后端的其他數據庫 支持不同了。sns網站可能最常調用的會是好友關系和個人信息的接口，這樣的接口是不是需要獨立出來處理？這樣的請求會很多是重復的，是不是考慮使用中間件或者緩存來減輕對其他數據庫 的直接壓力呢？運營數據一般使用單表就可以解決的。個人覺得運營中統計的需求是最難做的。首先統計並不是任意的統計要求都可以滿足，這個需要和產品討論需求。其次，統計一般需要使用些訪問日志之類的，可能涉及到許多shell腳本。
api開發
其 實相對於web開發，api開發是屬於被動的。意思就是，由於客戶端可能是手機產品，可能是pc產品。往往都是有發布和版本的。這個意味着api接口沒法 像web那樣為所欲為隨時更新代碼。它更多需要考慮到各個版本之間的兼容問題。兼容問題在很大程度上會變為加法，永遠不會是減法。個人感覺，如果毫無節制 地滿足需求，隨着版本越來越多，你的代碼中會越來越多if else，到最后，你的代碼就根本無法維護了。然后就會是別人來接手你的工作，踩坑，邊罵邊重構….api開發是最需要依賴測試的。往往只有測試人員才對 各個版本的小改動，小特性如數家珍。
再考慮到非功能配套：
你可能需要對api調用時間進行統計，這樣你才明白你的接口表現如何。
你的代碼可能還會用到其他機器上的服務，比如curl一個其他服務，這樣的情況，最好考慮下錯誤處理和日志記錄。
對於有金錢交易的接口服務，日志處理更是必不可少。
對於一些內部錯誤，最好不需要直接拋出顯示給用戶，所以需要使用的最好是白名單錯誤機制。
接口的加密方式，一般最少是需要有個簽名機制的，考慮到加密方法，大致有幾種：對稱加密和非對稱加密。加密的時候就需要考慮到一些情況了，比如手機客戶端的用電量等。
如果是給手機開發 接口，需要考慮流量問題，圖片的規格問題。
框架永遠是會變的，不說需求的變化，單就用戶量的變化，20w用戶和1000w用戶的框架一定是不一樣的。剛開始的時候你不可能根據1000w的用戶量來設計框架來給20w人用。所以一個好的服務端框架一定是隨着用戶量變化會進行幾次大的變化的。
…
后記
這篇是想到哪寫到哪，寫到這里發現寫不下去了…總之，web服務開發的技巧和小東西還是很多的。有的坑是需要自己踩過才知道痛的。可愛的是，我還在繼續踩坑中…
補充下，接口重構幾乎是每個服務端開發人員必須經歷過的。相較於開發一個新系統，接口重構的難度可以說是翻翻，當然這里的難度也可以理解為難受程度…也會是很鍛煉人的一個活。對於重構來說，測試尤為重要，如何有個很好的測試集來保證你的重構的正確性是個難度。
=================================================
http://ruby-china.org/topics/7075
工具用http_load，在公司的服務器上做的測試，我這邊的帶寬不是問題
我在雲服務器上的rails應用，nginx+passenger $ http_load -p 5 -s 10 urls 175 fetches, 5 max parallel, 1.48505e+06 bytes, in 10 seconds 8486 mean bytes/connection 17.5 fetches/sec, 148505 bytes/sec msecs/connect: 11.7533 mean, 100.123 max, 1.872 min msecs/first-response: 253.544 mean, 1797.26 max, 50.015 min http response codes: code 200 -- 175
$ http_load -p 30 -s 10 urls 255 fetches, 30 max parallel, 2.16393e+06 bytes, in 10 seconds 8486 mean bytes/connection 25.5 fetches/sec, 216393 bytes/sec msecs/connect: 231.678 mean, 450.523 max, 1.917 min msecs/first-response: 595.631 mean, 2215.58 max, 142.245 min http response codes: code 200 -- 255
$ http_load -p 30 -s 30 urls 784 fetches, 30 max parallel, 6.65302e+06 bytes, in 30 seconds 8486 mean bytes/connection 26.1333 fetches/sec, 221767 bytes/sec msecs/connect: 310.235 mean, 450.555 max, 2.066 min msecs/first-response: 481.559 mean, 1282.8 max, 133.443 min http response codes: code 200 -- 784
$ http_load -p 50 -s 30 urls 780 fetches, 50 max parallel, 6.61908e+06 bytes, in 30 seconds 8486 mean bytes/connection 26 fetches/sec, 220636 bytes/sec msecs/connect: 518.74 mean, 750.023 max, 2.041 min msecs/first-response: 779.266 mean, 1890.49 max, 142.368 min http response codes: code 200 -- 780
qps到26就上不去了，latency在不斷變大 同時也測試了ruby-china和codecampo也是這樣的
===========================================
http://studiogang.blog.51cto.com/505887/386852
我們知道壓力測試的軟件其他 確實很多，諸如微軟的wast，惠普的loadrunner以及等等其他的，但這些軟件其他 學習起來還是需要花費些時間，在選擇上實在頭痛，后來在郭欣的那本《構建其他高性能 web站點》上看到了他介紹的這款apache自帶的壓力測試工具ab，十分喜愛，於是今天終於有機會體驗下ab對網站的壓力測試。
實驗之前我的apache已經安裝了，操作系統：ubuntu 10.04 vmware 7.0
1、先查看一下版本信息 ab -v（注意是大寫的v）
- studiogang@studiogang:~$ ab -v
- this is apachebench, version 2.3 <$revision: 655654 $>
- copyright 1996 adam twiss, zeus technology ltd, http://www.zeustech.net/
- licensed to the apache software foundation, http://www.apache.org/
2、我們也可以使用小寫的v查看下ab命令的一些屬性 ab -v
- studiogang@studiogang:~$ ab -v
- ab: option requires an argument -- v
- ab: wrong number of arguments
- usage: ab [options] [http[s]://]hostname[:port]/path
- options are:
- -n requests number of requests to perform
- -c concurrency number of multiple requests to make
- -t timelimit seconds to max. wait for responses
- -b windowsize size of tcp send/receive buffer, in bytes
- -p postfile file containing data to post. remember also to set -t
- -u putfile file containing data to put. remember also to set -t
- -t content-type content-type header for posting, eg.
- 'application/x-www-form-urlencoded'
- default is 'text/plain'
- -v verbosity how much troubleshooting info to print
- -w print out results in html tables
- -i use head instead of get
- -x attributes string to insert as table attributes
- -y attributes string to insert as tr attributes
- -z attributes string to insert as td or th attributes
- -c attribute add cookie, eg. 'apache=1234. (repeatable)
- -h attribute add arbitrary header line, eg. 'accept-encoding: gzip'
- inserted after all normal header lines. (repeatable)
- -a attribute add basic www authentication, the attributes
- are a colon separated username and password .
- -p attribute add basic proxy authentication, the attributes
- are a colon separated username and password .
- -x proxy:port proxyserver and port number to use
- -v print version number and exit
- -k use http keepalive feature
- -d do not show percentiles served table.
- -s do not show confidence estimators and warnings.
- -g filename output collected data to gnuplot format file.
- -e filename output csv file with percentages served
- -r don't exit on socket receive errors.
- -h display usage information (this message)
- -z ciphersuite specify ssl/tls cipher suite (see openssl ciphers)
- -f protocol specify ssl/tls protocol (ssl2, ssl3, tls1, or all)
3、現在我們就對51cto的網站進行一次壓力測試吧，使用命令ab -n1000 -c10 http://www.51cto.com/index.php，其中 -n1000 表示總請求數 -c10表示並發用戶數為10 http://www.51cto.com/index.php 表示請求的url，下面是測試的結果，其中我們最關心的三個指標，我已經注釋出來了。
- studiogang@studiogang:~$ ab -n1000 -c10 http://www.51cto.com/index.php
- this is apachebench, version 2.3 <$revision: 655654 $>
- copyright 1996 adam twiss, zeus technology ltd, http://www.zeustech.net/
- licensed to the apache software foundation, http://www.apache.org/
- benchmarking www.51cto.com (be patient)
- completed 100 requests
- completed 200 requests
- completed 300 requests
- completed 400 requests
- completed 500 requests
- completed 600 requests
- completed 700 requests
- completed 800 requests
- completed 900 requests
- completed 1000 requests
- finished 1000 requests
- /*其他web服務器 用的是nginx*/
- server software: nginx
- server hostname: www.51cto.com
- server port: 80
- document path: /index.php
- document length: 154 bytes
- concurrency level: 10
- time taken for tests: 74.373 seconds
- complete requests: 1000
- failed requests: 0
- write errors: 0
- non-2xx responses: 1000
- total transferred: 330000 bytes
- html transferred: 154000 bytes
- /*大家最關心的指標之一，指的是吞吐率
- 相當於 lr 中的 每秒事務數 ，后面括號中的 mean 表示這是一個平均值*/
- requests per second: 13.45 [#/sec] (mean)
- /*大家最關心的指標之二，指的是用戶平均請求等待時間
- 相當於 lr 中的 平均事務響應時間 ，后面括號中的 mean 表示這是一個平均值*/
- time per request: 743.726 [ms] (mean)
- /*大家最關心的指標之三，指的是服務器平均請求處理時間
- time per request: 74.373 [ms] (mean, across all concurrent requests)
- transfer rate: 4.33 [kbytes/sec] received
- connection times (ms)
- min mean[+/-sd] median max
- connect: 129 163 245.3 145 3154
- processing: 129 576 1510.8 147 11756
- waiting: 129 567 1502.0 147 11756
- total: 261 739 1543.7 294 11888
- percentage of the requests served within a certain time (ms)
- 50% 294
- 66% 297
- 75% 304
- 80% 308
- 90% 1290
- 95% 3452
- 98% 7582
- 99% 7962
- 100% 11888 (longest request)
4、為了使結果更有對比性，我們將並發用戶更改為100個進行壓力測試，我這里只將三個指標貼出來。
- requests per second: 190.95 [#/sec] (mean)
- time per request: 523.694 [ms] (mean)
- time per request: 5.237 [ms] (mean, across all concurrent requests)
5、將並發用戶改為200個進行測試
- requests per second: 186.00 [#/sec] (mean)
- time per request: 1149.433 [ms] (mean)
- time per request: 5.747 [ms] (mean, across all concurrent requests)
6、500個並發用戶時的情況
- requests per second: 180.99 [#/sec] (mean)
- time per request: 2631.662 [ms] (mean)
- time per request: 5.263 [ms] (mean, across all concurrent requests)
我們來分析下測試的結果，先對比下吞吐率，當並發用戶的時候吞吐率最高為190 reqs/s,當並發用戶數為200,500 吞吐率下降了，隨之用戶的等待時間更是明顯增加了，已經有2s的等待時間了。這說明性能明顯下降了。當然分析這個測試結果並不是說明51cto的網站的並 發用戶只能在500左右，因為我是在服務器負荷的情況下就行測試的，這顯然不能說明問題。另外我們在生產環境下測試的時候，最好能將測試結果做成報表 ，這樣可以非常清晰地對比出問題來，好了，我該准備下，給上面提交一份我們公司網站的測試報告了。