如何使用 Apache ab 以及 进行压力测试？（如何使用tiktok）

如何使用 Apache ab 以及 进行压力测试？（如何使用tiktok）

下一个 release 准备小长假后就要 go-live ，所有的测试 case 都 cover 过了，但还未进行过压力测试，有点不放心，刚好过节期间家人都回家去了，假期终于可以抽点时间压测一把。

Apache ab 压测

总共进行了两轮压测, 测试方式及结果:

第一轮： 每秒大概 30 个并发, 单页面访问第二轮：并发量每秒提升到 100，分别访问 4 个主页面

使用 ab 进行测试的方式：

ab -n 1000 -c 30

-n 是指总的 request 数量，-c 是指同一时间并发量

以下是在添加了 Ruby agent之后，使用 apache ab 压测结果。

总体拓扑

通过拓扑图来展示应用的端到端调用关系、应用服务器与数据库、外部 服务的调用关系以及应用之间的调用关系。同时，通过在拓扑图中将相应模块标记成不同颜色。

由于只是压测，就没有在测试环境部署相关的后台任务，也没做集群以及 LA , 在我们的 prod 环境中，是有座 cluster 及 Load balance。

总览

30 并发 /s 的平均响应时间在 200ms 左右，而一旦提升到 100 并发 /s，响应时间瞬间飙升到 800～900ms 左右，对于一个目前 pv 还不算高的网站，还可以接受，但也还有提升空间。

Web 事务

数据库

MongoDB 在单机压力测试下表现还可以，如果说整体上整个站点要在优化性能的话，主要就是在 framework 上。

RubyVM

结论

除了用于定位应用线上的问题，还配合使用 ab 压测在项目上线前提早预知一些可能的性能瓶颈， 的 Dashboard 就是一个很好的压测结果报告，压测前后的性能差异一目了然，不需在通过一些命令再去对比 Response time 之类的数据，总之省力很多。

比较传统的方式是下图这样对比性能，编辑 bench 了一个 url 之后得到输出结果：

客观的从纯性能的角度出发，在生产环境中，Ruby 还是只适合 Small Business 。对与压力较高的服务或应用，就必须投入大量额外的硬件资源才能维持。

最后的最后：不要在正式环境做压力测试！！！