服務器詳細配置
|
Project |
message |
|
System info |
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch Distributor ID: CentOS Description: CentOS release 6.6 (Final) Release: 6.6 Codename: Final |
|
Harddriver |
2core4GB |
|
software |
nginx 1.6.2 mysql 5.5 PHP 5.4.36 |
|
Core set |
ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30459 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65535 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited |
標準的性能曲線
什么樣的曲線才是健康的呢?看看下面的幾幅圖.
“乳狀圖”
這幅圖中不管是http每秒的請求數,還是服務器的請求的命中率都呈現了波浪狀.這是非常不健康的情況.導致的原因也可能是多方多面.即可能是web服務器自身性能的問題,也可能是被壓測機自身的問題,除此外,網絡誘因,網卡流量,壓測軟件內存原因都可能導致這樣的問題出現
“有病在身”
這幅圖粗看好像正常的樣子,零錯誤率而且各曲線似乎都很平滑,略有起浮似乎可以接受.但如果仔細分析就會發現其中的貓膩.
下面四幅曲線圖依次為bytes/sec ResponseTime of/vusers https/sec
-Bytes/sec – 和壓測頁面的大小有密切關系,所以不容易判斷健康狀態
–ResponseTime – 小到1大到4, 要知道用戶的耐心經過科學的統計是在1s以內的.以此為準每延后0.2s就會有10%左右的用戶流失,這個數據不容小視
–Of/vusers – 這個數值即和壓測機有關也和被壓測機有關.這里平穩的1000用戶同時壓測正常
–Https/sec – 這個數據這里只有3000是不正常的.看過webbench/ab和loadrunner區別這篇文章的同學應該對webbench/ab的性能有一定的了解.每秒在270左右的.這個數值大家可以大概計算下.不過發現每次的數據因為并發人數的多少會有非常明顯的變化,數據還是供大家參考吧~
簡單測試了下 100個并發用戶和10個并發用戶相差還真是大~~又壓了1000看看~~
數據大家參考下吧~也差不多能看到個大概
健康圖
并發950用戶,壓測15min20s,總共704w請求數,錯誤率大概在0.0000 02吧~
服務器響應延遲也一直在1s內,每秒平均響應數在8000.非常平衡的輸出
5w并發壓測無負載
在壓測過程中,因為苦于沒有數據作參考,整個壓測過程中很多次數據都是在臆想和yy,在一次的數據壓測中我們準備了3臺性能和壓測機硬件配置完全一樣的機器,外加一臺硬件內存,cores數是壓測機2倍的服務器,外加3臺并發2000的服務器,加起來最少5w的并發進行性能壓測,結果
因為負載過高,我們壓爆了2臺被壓測機, 但壓測服的性能一直只在0.1-0.4徘徊,非常讓我個人吃驚.雖然說張宴的博客中說nginx配置可以支持單臺并發10w,但幾個方面的原因使人對結果是極其懷疑的.
1. 我們的服務器是阿里云的虛擬機
2. 我們服務器的配置只有2c4g
3. 了解其它朋友的服務器64G32cores才并發3w請求數(是服務器端每秒處理3w請求數,不是3w用戶并發訪問),最關鍵的是他們的服務器是做proxy的~~~
4. 我們調用的被壓測機配置甚至比壓測服務器配置要高,而且數量也多太多~~
后來,雖然我們也
a> 借用本地物理機進行壓測;
b> 完全重裝系統重新再來;
但發現數據也一直是支持5w并發用戶并且是輕松支持的.幾次的折騰也使我個人有很長一段時間也不得不相信并發5w的數據~
一次偶然的情況,忽然發現nginx配置中有關于fastcgi_cache的配置~
#fastcgi_cache_path /data/cache/fastcgi levels=1:2 keys_zone=FastCGICache:10m inactive=5m; #fastcgi_cache FastCGICache; #fastcgi_cache_methods GET HEAD; #fastcgi_cache_use_stale error timeout invalid_header http_500; #fastcgi_intercept_errors on; #fastcgi_cache_valid 200 302 1h; #fastcgi_cache_valid 301 1d; #fastcgi_cache_valid any 1m; #fastcgi_cache_min_uses 1; #fastcgi_cache_key $request_method://$host$request_uri; |
再認真確認下我們的壓測腳本,發現我們的壓測腳本訪問的是一個頁面~so,大家明白了吧~~~想撞死南墻的想法的都有了~~~
Loadrunner在window上的”坑”
對于loadrunner運行在windows還是linux上這里不做個人建議. 如果對windows有深入研究,對loadrunner在windows上運行機理有可靠的把控可以使用windows系統為繼續,本次我們遇到的問題包括
Error：timed out Error：Server“192.168.2.192”has shut down the connection prema Failed to connect to server 'hostname';port_ld':
但因為測試成員對window了解程度也是一般,同時中文博客的不嚴謹性,也導致我們在處理這樣的問題的時候一直處于被動猜測問題的層面,同時也是因為windows是閉源的,網上對這塊的問題也基于 抄襲的層面,解決問題非常困難~~~
最后只有一句話, 珍愛生命請用linux
在linux上壓測圖,
最后小結
-
了解什么是健康的壓測圖
-
.健康的標準主要包括四個方面:
-
ResponseTime: 1s內且平穩
-
of/vusers 2g4c 1000以上
-
https/sec 1000人8000qts
-
errors 0.3%以內
-
多報以質疑的態度治學
-
相信權威但不迷信權威
~~~~~~~Over
原創文章，作者：stanley，如若轉載，請注明出處：http://www.www58058.com/3316
