上面具体每一项代码什么意义可以网上查找，这里我们主要关心一下如下这个选项：
　　Requests per second，从结果看这个值是13283.74 [#/sec] (mean)，表示每一秒钟可以处理13283.74各请求，因为我这个很简单的一个静态页面（是apache服务器安装后默认的首页），所以看起很不错，而且是通过本地localhost，没有经过网络。我们可以改变访问的条件持续做很多组测试，例如我把并发请求数改为100，即-c100，得到参数值为：
　　Requests per second:    11843.29 [#/sec] (mean)
　　明显比上面减少了一些，继续改总请求数为10000，并发数1000，即-n10000 -c1000得到如下值：
　　Requests per second:    747.98 [#/sec] (mean)
　　这个时候减少的相当的可怕了，所以通过这个ab测试工具能够知道我们的web应用能够承担多少的并发访问，当然我们可以通过不断的挑战参数进行测试，然后绘制成一个曲线图观察很方便看出我们web应用的佳性能点，超过那么佳性能点可能导致性能下降，那么访问速度也跟着下降了。
　　当然只看上面一个参数看不出具体一个用户访问所需要等待的时间，另一个参数可以看出，我对应三次的测试这个参数值分别如下：
　　Time per request:       0.753 [ms] (mean)
　　Time per request:       8.444 [ms] (mean)
　　Time per request:       1336.942 [ms] (mean)
　　从三次测试可以看出，随着并发数的增长，一个用户平均等待的时间也在变长，这个终反应到用户web访问的结果（速度的快慢），这里测试的只是一个简单的静态网页，如果是复杂的动态网页（例如访问数据库，读写磁盘和大量的计算等）那么更加复杂了，一个请求的快慢由于web应用需要处理的业务逻辑有很大的关系，当然怎样让这些业务逻辑执行更快并且并行执行，这个需要程序实现者考虑了。
　　总结
　　这里只是简单介绍了部署在PAAS平台web应用访问很慢的可能原因和简单定位方法，起始我觉得大家应该中的关注在第三点上，自身应用的优化，因为前面两点都是我们不可控的，网络这个PAAS平台自身也解决不了，多可以部署多个机房多个宽带运营商和cdn处理等，但是用户自身的网络问题PAAS平台也是解决不了的。至于PAAS平台自身的原因，大家更不用担心了，他们比你们更关系自身PAAS平台的性能，因为上面托管着成千上万的web应用，他们时时刻刻都在关系着自身平台的性能拼劲，想着各种方法优化。如果PAAS平台的原因导致用户部署的web应用访问很慢甚至不可用那么这个PAAS平台自身也做不下去的。
　　后还想强调一点是web应用自身的性能优化问题，现在各种语言都提供了很好的开发框架，理论上都是稳定的并且性能是不错的，当然特殊场景需要特殊考虑。但是我们自身在设计web应用的时候可能需要考虑的更多，不要妄想一个简单的开发框架能解决所有的问题，尤其是性能问题。设计到web应用优化的知识和技术非常的多也非常的复杂，还有很多场景，所以这是各长久的过程。后面有机会也会给大家介绍一些web性能优化的方法和技术，并且结合实际场景进行分析和演练。