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，是我配置有问题吗？