上面具体每一项代码什么意义可以网上查找，这里我们主要关心一下如下这个选项：
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性能优化的方法和技术，并且结合实际场景进行分析和演练。
