apfree_wifidog性能测试报告
========
# 测试目的 #
如何调节线程数和列队深度使得wifidog处于一个相对均衡点（保证响应速度合适和最大并发失败率最低）

## 测试工具说明 ##
使用http_load测试工具测试，修正使用Weebench测试盲区Weebench会把wifidog列队溢出的数据列为成功响应数据，
http_load则会把溢出数据列为失败数据，更加精准，

## 测试环境和环境部署 ##
路由器X86网关端：
CPU：Intel(R) Atom(TM) CPU D525 @ 1.80GHz
关闭防火墙的防止洪水攻击，vi /etc/config/firewall option syn_flood	 设置为0 重启防火墙，保证并发有效。
PC端：
CPU：Intel(R) i5 6500 虚拟机分配4g内存 2个处理器。
安装http_load工具，使用有线连接，模拟带二级路由器，排查wifi干扰因素。

## 测试理论 ##
通过前台debug wifidog 查看列队溢出，以及其他异常情况（目前除了列队溢出，没出现其他锁死之类的异常情况）
查看http_load结果，分析失败概率，以及响应时间，通过结果推导最优阀门参数


## 所有场景均在线程池模式运行 ##

## 线程数影响分析 ##
### 设置线程数为5， 队列数20。设置http并发数25，运行30S ###
debug数据：溢出778个数据，top：cpu利用率75左右 人眼观看的
pc数据：发送26943数据。失败772，返回307:26171，平均响应25.6954ms，最慢响应137.339ms，最快响应0.254ms

### 设置线程数为10， 队列数20。设置http并发数25，运行30S ###
debug数据：溢出14个数据，top：cpu利用率80左右   	          
pc数据：发送28904数据。失败14，返回307:28890，平均响应23.7935ms，最慢响应229.247ms，最快响应1.123ms
## 对比上诉2个结果加大线程数可以有效减少失败率，但是最慢响应速度会有所加大，并不会影响太大的体验，保证成功率是关键 ##

### 设置线程数为15， 队列数20。设置http并发数25，运行30S ###
debug数据：溢出18个数据，top：cpu利用率82左右   	          
pc数据：发送31959数据。失败18，返回307:31941，平均响应21.1775ms，最慢响应274.758ms，最快响应2.179ms

### 对比上诉2个结果加大线程数继续加大，并没有实际意义，反而会使得最慢响应有所增加。 ###
### 线程数目前最优值设置为10对应路由器合适，通过加大并发数结果3个也是成线性增加，这里不做阐述。 ###




## 队列深度数影响分析 ##
### 设置线程数为10， 队列数20。设置http并发数25，运行30S ###
debug数据：溢出14个数据 	          
pc数据：发送28904数据。失败14，返回307:28890，平均响应23.7935ms，最慢响应229.247ms，最快响应1.123ms

### 设置线程数为10， 队列数40。设置http并发数25，运行30S ###
debug数据：溢出0个数据   	          
pc数据：发送30785数据。失败0，返回307:30785，平均响应22.1519ms，最慢响应229.986ms，最快响应3.319ms

结论：明显加大列队深度可以有效减少溢出失败率，而去能力有余的时候不会影响响应时间，下面加大并发数

### 设置线程数为10， 队列数40。设置http并发数50，运行30S ###
debug数据：溢出0个数据 	          
pc数据：发送30617数据。失败0，返回307:30617，平均响应30.8458ms，最慢响应432.654ms，最快响应5.051ms

### 结论：并发数的加大 还在wifidog能力范围，但是效率上已经有所减低，响应时间慢了一倍。 ###
### 由于PC端速度不够，基本上吞吐量已经满载运行，大致线程数和列队深度调整思路就是这样。 ###





