SCUTOJ 建站手记（3）--- 压力测试 & 性能监控

又是抽一些空隙时间，基本完成了SCUTOJ的压力测试，参考的是《构建高性能web站点》，但是过程中还是遇到不少问题，这里记录下。

硬件环境：

首先是在本机用 webbench 这个小巧的测试工具对远端的服务器进行测试。小是小了，可惜功能太少，结果太简单。

可以看到，并发数分别为：100， 500，1000，2000，持续时间均为30秒。
页面响应速度分别为： (pages/min)
5244
5220
6950   fail : 0.7 %
8022   fail : 2%

从1000开始已经出现fail了, 并且随着并发数增加，失败概率不断增大。

再看一下apache mod_status 的数据：

空闲的时候其实只有4个线程（worker），并发数500的时候已经升到138了，到1000的时候好像也没有大的变化。看了一下apahce2.conf，maxClient设置为150.

由于webbench测试是在图书馆做的，带宽还是挺不错的，看了一下下行速度，有1M多每秒。应该说线路带宽当面对结果不会有太大影响，延迟就不敢保证了 = =



==============================

压力测试一般要不要在本机进行，这个一直都没个定论，我觉得视具体情况而定吧，所以我都测了。在server上用apahce自带的ab，感觉还是蛮好用的，主要是结果比较详细，但是发现了一些新的问题。

也是做了6组测试：
ab -n 10000 -c X http://127.0.0.1/index.php
X分别为 1，10，50，100，300，500

关键参数：
Requests per second     //每秒处理请求数，也就是吞吐率
Time per request           //每个请求的处理时间，即用户平均等待时间
Time per request across all concurrent requests     //服务器平均处理时间，也就是总时间 / 总请求
Transfer rate                 //反应CPU资源耗尽时出口带宽的需求极限


结果如下：
1）

Requests per second:    388.64 [#/sec] (mean)
Time per request:       2.573 [ms] (mean)
Time per request:       2.573 [ms] (mean, across all concurrent requests)
Transfer rate:          1951.53 [Kbytes/sec] received

10）

Requests per second:    745.81 [#/sec] (mean)
Time per request:       13.408 [ms] (mean)
Time per request:       1.341 [ms] (mean, across all concurrent requests)
Transfer rate:          3747.93 [Kbytes/sec] received


50）

Requests per second:    722.33 [#/sec] (mean)
Time per request:       69.221 [ms] (mean)
Time per request:       1.384 [ms] (mean, across all concurrent requests)
Transfer rate:          3636.58 [Kbytes/sec] received

100）

Requests per second:    702.03 [#/sec] (mean)
Time per request:       142.444 [ms] (mean)
Time per request:       1.424 [ms] (mean, across all concurrent requests)
Transfer rate:          3540.54 [Kbytes/sec] received




300）

Requests per second:    640.58 [#/sec] (mean)
Time per request:       468.323 [ms] (mean)
Time per request:       1.561 [ms] (mean, across all concurrent requests
Transfer rate:          3251.50 [Kbytes/sec] received

可以看出，并发量为10时的效率最高。也跟现实中的情况比较接近，好吧，小站小规模 = =
当然，同时在线 != 并发

测试500并发，几次都不成功，报错主要集中是：
apr_socket_recv: Connection timed out (110)
apr_socket_recv: Connection reset by peer (104)

查系统日志 /var/log/syslog ，发现很多错误记录：

possible SYN flooding on port 80. Sending cookies.
nf_conntrack: table full, dropping packet.
TCP: time wait bucket table overflow


google一下，发现问题。简单的说，ip_conntrack就是linux NAT的一个跟踪连接条目的模块，ip_conntrack模块会使用一个哈希表记录 tcp 通讯协议的 established connection记录，当这个哈希表满了的时候，便会导致nf_conntrack: table full, dropping packet错误。挺郁闷的感觉，哪里来的NAT防火墙？貌似是跟XEN的虚拟路由技术有关？


==============================

由于我在宿舍用的是电信宽带，没有固定IP，所以如果要自己实现监控服务器性能的话，应该说没有太好的方案。以前在SJTU的时候，由于是内网服务器集群，所以Ganglia使用起来非常方便，配合Hadoop更是得心应手，因为Hadoop有原生支持Ganglia的监控插件（gmetric）。做数据分析实验的时候可以从Ganglia的web front-end 看到很清晰的各种细化数据，还有自定义的监控信息。更重要的是，这是自己折腾出来的~
但是现在单个VPS监控就比较难办了，上网查了好一阵也没有特别好的方案，有人推荐监控宝，姑且试下。

监控宝是利用SNMP实现信息换取，要开启SNMP的话参考官方wiki就可以。原来找到个ubuntu 10.04上的安装文档，折腾半天发现原来是net-snmp的版本号不对，配置文件的位置变了。。。 = = 原来以为版本变化不大，应该可以吧。。。结果Orz

配好服务器性能监控的SNMP v3之后，顺便加上Apache的监控。也是因为我的IP不固定，所以server-status的配置不好设，干脆一并放在监控宝上面好了。

就目前来看，监控效果还勉强过得去，但是免费用户监控频率比较低，竟然是5 min...平时总体看看趋势还可以，如果真的到高并发高负载的时候就太不靠谱了吧。。。当然，可以用来备份数据用以分析，大概也只能这样了。。。想想以前自己搭的Ganglia都是每分钟采样的，比较重要的数据是半分钟采样，用python脚本 + crond实现的。。。Orz

然后，同时还加上CNZZ的访问数据统计，感觉这个是真的挺有用的，访客数据非常详细，分类也比较清晰。

综合目前使用的网络工具
alibench         网站全景性能测试
jiankongbao  服务器性能监控
CNZZ           访问数据统计