服务器详细配置
|
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.178linux.com/3316
