阿里云2G2C的ECS部署LNMP性能瓶颈到底在多少


服务器详细配置

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服务器自身性能的问题,也可能是被压测机自身的问题,除此外,网络诱因,网卡流量,压测软件内存原因都可能导致这样的问题出现

1.png

有病在身


这幅图粗看好像正常的样子,零错误率而且各曲线似乎都很平滑,略有起浮似乎可以接受.但如果仔细分析就会发现其中的猫腻.

下面四幅曲线图依次为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左右的.这个数值大家可以大概计算下.不过发现每次的数据因为并发人数的多少会有非常明显的变化,数据还是供大家参考吧~ 

阿里云2G2C的ECS部署LNMP性能瓶颈到底在多少

简单测试了下 100个并发用户和10个并发用户相差还真是大~~又压了1000看看~~

阿里云2G2C的ECS部署LNMP性能瓶颈到底在多少

数据大家参考下吧~也差不多能看到个大概

4.jpg

健康图

并发950用户,压测15min20s,总共704w请求数,错误率大概在0.0000 02吧~5.png

服务器响应延迟也一直在1s内,每秒平均响应数在8000.非常平衡的输出

6.png

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.     我们调用的被压测机配置甚至比压测服务器配置要高,而且数量也多太多~~

阿里云2G2C的ECS部署LNMP性能瓶颈到底在多少

阿里云2G2C的ECS部署LNMP性能瓶颈到底在多少

后来,虽然我们也

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,大家明白了吧~~~想撞死南墙的想法的都有了~~~

Loadrunnerwindow上的


对于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上压测图,

9.png

最后小结


  • 了解什么是健康的压测图

  • .健康的标准主要包括四个方面:

    • ResponseTime:   1s内且平稳

    • of/vusers   2g4c 1000以上

    • https/sec  1000人8000qts

    • errors   0.3%以内

  • 多报以质疑的态度治学

  •  相信权威但不迷信权威

~~~~~~~Over


原创文章,作者:stanley,如若转载,请注明出处:http://www.178linux.com/3316