下一个 release 准备小长假后就要 go-live ，所有的测试 case 都 cover 过了，但还未进行过压力测试，有点不放心，刚好过节期间家人都回家去了，假期终于可以抽点时间压测一把。
Apache ab 压测
之前用过一些压力测试工具比如 loadrunner， Jmeter，感觉都太重，想要使用不是软件需要注册就是使用起来很不得心应手，这次灵光一动，想到直接使用 ab ＋ OneAPM 进行测试，ab 的全称是 ApacheBench , 是 apache http server 自带的一个测试工具，专门用于 HTTP Server 的 benchmark testing，可以同时模拟多个并发请求。公司的开发人员也在用它作一些测试，看起来也不错，很简单，也很容易使用。可以对你的 Web 站点进行压力测试，非常小，使用起来很简单。
如果你已经安装了 apache，那么在 <apache>/bin 目录就能找到 ab，输入ap --help `, 里面简单几个选项仔细读一下，很快就能上手进行测试。官方使用文档：https://httpd.apache.org/docs/2.4/programs/ab.html
OneAPM
这个就不用多说了，性能监控软件，如何使用参看下官网的 guide，我分别在不同的平台上都试过接入 OneAPM，比如 node.js，ruby，php，java，使用起来挺简单方便的。
| 环境： | 内网测试服务器 |
| 语言： | Ruby |
| Framework： | ror |
| 数据库： | MongoDB |
总共进行了两轮压测, 测试方式及结果:
- 第一轮： 每秒大概 30 个并发, 单页面访问
- 第二轮：并发量每秒提升到 100，分别访问 4 个主页面
使用 ab 进行测试的方式：
ab -n 1000 -c 30 <your url>
-n 是指总的 request 数量，-c 是指同一时间并发量
以下是在添加了OneAPM Ruby agent之后，使用 apache ab 压测结果。
总体拓扑
OneAPM 通过拓扑图来展示应用的端到端调用关系、应用服务器与数据库、外部 服务的调用关系以及应用之间的调用关系。同时，通过在拓扑图中将相应模块标记成不同颜色。
由于只是压测，就没有在测试环境部署相关的后台任务，也没做集群以及 LA , 在我们的 prod 环境中，是有座 cluster 及 Load balance。
总览
30 并发 /s 的平均响应时间在 200ms 左右，而一旦提升到 100 并发 /s，响应时间瞬间飙升到 800～900ms 左右，对于一个目前 pv 还不算高的网站，还可以接受，但也还有提升空间。
Web 事务
数据库
MongoDB 在单机压力测试下表现还可以，如果说整体上整个站点要在优化性能的话，主要就是在 framework 上。
RubyVM
这个对于实时监控挺有用，但是这个仅仅是适用 vm 以及 ruby gc 的一些统计，如果能加入对 ruby container 的监控就更好了，因为我遇到过很多次，web 缓慢或者瘫痪的时候，几次都是因为 ruby container 内存溢出，导致宕机。但是对这块的监控就比在 ruby 或者 ror 中加探针要复杂很多了。
结论
OneAPM 除了用于定位应用线上的问题，还配合使用 ab 压测在项目上线前提早预知一些可能的性能瓶颈，OneAPM 的 Dashboard 就是一个很好的压测结果报告，压测前后的性能差异一目了然，不需在通过一些命令再去对比 Response time 之类的数据，总之省力很多。
比较传统的方式是下图这样对比性能，编辑 bench 了一个 url 之后得到输出结果：
客观的从纯性能的角度出发，在生产环境中，Ruby 还是只适合 Small Business 。对与压力较高的服务或应用，就必须投入大量额外的硬件资源才能维持。
最后的最后：不要在正式环境做压力测试！！！
本文系国内 ITOM 行业领军企业 OneAPM 经授权转载自 cnode 社区。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客