ab,qps,服務器性能壓力

ab,qps,服務器性能壓力

  做者及來源： 陳聽溪 - 博客園    收藏到→_→：

 

摘要: ab,qps,服務器性能壓力

 

 http://www.makaidong.com/%E5%8D%9A%E5%AE%A2%E5%9B%AD%E7%9F%A5%E9%81%93/17732.shtml

 

 

"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/

軟件其餘 性能測試的基本概念和計算公式

1、軟件其餘 性能的關注點

對一個軟件其餘 作性能測試時須要關注那些性能呢？

咱們想一想在軟件其餘 設計、部署、使用、維護中一共有哪些角色的參與，而後再考慮這些角

 

此文來自: 馬開東博客 轉載請註明出處 網址： http://www.makaidong.com

色各自關注的性能點是什麼，做爲一個軟件其餘 性能測試工程師，咱們又該關注什麼？

首先，開發軟件其餘 的目的是爲了讓用戶使用，咱們先站在用戶的角度分析一下，用戶須要關注哪些性能。

對於用戶來講，當點擊一個按鈕、連接或發出一條指令開始，到系統把結果已用戶感知的形式展示出來爲止，這個過程所消耗的時間是用戶對這個軟件其餘 性能的直觀印象。也就是咱們所說的響應時間，當相應時間較小時，用戶體驗 是很好的，固然用戶體驗 的響應時間包括我的主觀因素和客觀響應時間，在設計軟件其餘 時，咱們就須要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，咱們能夠將先提取出來的數據展現給用戶，在用戶看的過程當中繼續進行數據檢索，這時用戶並不知道咱們後臺在作什麼。

用戶關注的是用戶操做的相應時間。

其次，咱們站在管理員的角度考慮須要關注的性能點。

一、 相應時間
二、 服務器資源使用狀況是否合理
三、 應用服務器 和其餘數據庫 資源使用是否合理
四、 系統可否實現擴展
五、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
六、 系統性能可能存在的瓶頸在哪裏
七、 更換那些設備能夠提其餘高性能
八、 系統可否支持7×24小時的業務訪問

再次，站在開發（設計）人員角度去考慮。

一、 架構設計是否合理
二、 其餘數據庫 設計是否合理
三、 代碼是否存在性能方面的問題
四、 系統中是否有不合理的內存使用方式
五、 系統中是否存在不合理的線程同步方式
六、 系統中是否存在不合理的資源競爭

那麼站在性能測試工程師的角度，咱們要關注什麼呢？

一句話，咱們要關注以上全部的性能點。

2、軟件其餘 性能的幾個主要術語

一、響應時間：對請求做出響應所須要的時間

網絡傳輸時間：n1+n2+n3+n4

應用服務器 處理時間：a1+a3

其餘數據庫 服務器處理時間：a2

響應時間=n1+n2+n3+n4+a1+a3+a2

二、併發用戶數的計算公式

系統用戶數：系統額定的用戶數量，如一個oa系統，可能使用該系統的用戶總數是5000個，那麼這個數量，就是系統用戶數。

同時在線用戶數：在必定的時間範圍內，最大的同時在線用戶數量。
同時在線用戶數=每秒請求數rps（吞吐量）+併發鏈接數+平均用戶思考時間

平均併發用戶數的計算：c=nl / t

其中c是平均的併發用戶數，n是平均天天訪問用戶數（login session），l是一天內用戶從登陸到退出的平均時間（login session的平均時間），t是考察時間長度（一天內多長時間有用戶使用系統）

併發用戶數峯值計算：c^約等於c + 3*根號c

其中c^是併發用戶峯值，c是平均併發用戶數，該公式遵循泊松分佈理論。

三、吞吐量的計算公式

指單位時間內系統處理用戶的請求數

從業務角度看，吞吐量能夠用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量

從網絡角度看，吞吐量能夠用：字節/秒來衡量

對於交互式應用來講，吞吐量指標反映的是服務器承受的壓力，他可以說明系統的負載能力

以不一樣方式表達的吞吐量能夠說明不一樣層次的問題，例如，以字節數/秒方式能夠表示數要受網絡基礎設施、服務器架構、應用服務器 制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器 和應用代碼的制約體現出的瓶頸。

當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在必定的聯繫，能夠採用如下公式計算：f=vu * r /

其中f爲吞吐量，vu表示虛擬用戶個數，r表示每一個虛擬用戶發出的請求數，t表示性能測試所用的時間

四、性能計數器

是描述服務器或操做系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮着「監控和分析」的做用，尤爲是在分析通通可擴展性、進行新能瓶頸定位時有着很是關鍵的做用。

資源利用率：指系統各類資源的使用狀況，如cpu佔用率爲68%，內存佔用率爲55%，通常使用「資源實際使用/總的資源可用量」造成資源利用率。

五、思考時間的計算公式

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

1、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 六、http response codes: code 200 -- 49     說明打開響應頁面的類型，若是403的類型過多，那可能

要注意是否系統遇到了瓶頸。 特殊說明： 測試結果中主要的指標是 fetches/sec、msecs/connect 這個選項，即服務器每秒可以響應的查詢次數，

用這個指標來衡量性能。彷佛比 apache的ab準確率要高一些，也更有說服力一些。 qpt-每秒響應用戶數和response time，每鏈接響應用戶時間。 測試的結果主要也是看這兩個值。固然僅有這兩個指標並不能完成對性能的分析，咱們還須要對服務器的

cpu、men進行分析，才能得出結論

2、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/

3、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文件. 4、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

六、 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時間乘以併發請求數

三、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 requests

server software: apache/2.2.15
server hostname: 192.168.80.157
server port: 80

document 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

一、先查看一下版本信息 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/

 二、咱們也可使用小寫的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)

三、如今咱們就對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)

四、爲了使結果更有對比性，咱們將併發用戶更改成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)

五、將併發用戶改成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)

六、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左右，由於我是在服務器負荷的狀況下就行測試的，這顯然不能說明問題。另外咱們在生產環境下測試的時候，最好能將測試結果作成報表 ，這樣能夠很是清晰地對比出問題來，好了，我該準備下，給上面提交一份咱們公司網站的測試報告了。