ab跟http_load的测试对比
当gu只有1个worker，我理解他没有并发能力，所有的请求都是顺序执行的。
所以 http_load -parallel 1 -fetches 1000 url 和 http_load -parallel
100 -fetches 1000 url 的总耗时是一样的，如果gu有并发能力,-parallel
100总耗时应该减少。为了方便说明，我这样对比测试：
gu只有1 worker，用ab压，1000个请求，分别-c1和-c100
1个并发:
qps:603.40
平均耗时(Time per request):1.657ms
总耗时(Time taken for tests):1.65s
100个并发:
qps:608.63
平均耗时(Time per request):164.302ms
总耗时(Time taken for tests):1.64s
当ab -n1000
-c100时，ab实际上是每次100个并发，分成10次完成1000个请求。这里的平均耗时164ms是每批次100个request全部完成后的耗
时，gu实际在执行时是顺序执行的，所以约等于1.65ms*100，http_load的测试结果和ab类似，1000个请求,分别
-parallel1和-parallel100
1个并发:
qps:609.40
平均耗时(msecs/first-response): 1.647ms
总耗时:1.647s
100个并发:
qps:654.534
平均耗时(Time per request):145.154ms
总耗时:1.527s
gu有8 worker时,再用ab压，同样是1000个请求，分别-c1和-c100
1个并发:
qps:544
平均耗时(Time per request):1.83ms
总耗时(Time taken for tests):1.85s
100个并发:
qps:4317
平均耗时(Time per request):23.16ms
总耗时(Time taken for tests): 0.23s
可以发现这次单个请求耗时没有变化(因为代码本身需要这么多时间来执行)，但100个并发时，总耗时降低到只有0.23s,原因是100
个并发请求基本被同时处理，所以只有10个顺序执行的'批次'，大大减少了总耗时。每批次耗时是23ms，总体qps提升到了4317。
http_load的测试结果和ab是类似的。
单个请求:
qps:483.187
平均耗时(msecs/first-response):1.83ms
总耗时:2.0s
100个并发:
qps:4287
平均耗时(msecs/first-response):20.5ms
总耗时:0.23s
好了，前面码了这么多字，其实我想说明的是，当-parallel增加时，qps也期望能提升，这个点现在是
-parallel=10，qps就无法提升了，如果再增加-parallel，msecs/first-response也随之增加，吞吐量无法再提
高。比如 http_load -parallel 200 -fetches 1000 urllist
时msecs/first-response会增加一倍，达到41.95ms。
当然这里的测试是纯cpu消耗的，所以并发提升有限，我之前的detail页面，平均耗时200ms，但这里有mysql,cache等
外部消耗时间，真正的cpu占用其实没有200ms，当一个request过来时，如果cpu在等待io，gu应该能智能的切换去处理另外一个
request，但现在貌似它在傻傻的wait，是我配置有问题吗？