如何使用 Apache ab 以及 OneAPM 进行压力测试？

下一个 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，使用起来挺简单方便的。

<table> <tbody> <tr> <td>环境：</td> <td>内网测试服务器</td> </tr> <tr> <td>语言：</td> <td>Ruby </td> </tr> <tr> <td> Framework： </td> <td>ror </td> </tr> <tr> <td>数据库： </td> <td>MongoDB </td> </tr> </tbody> </table> 总共进行了两轮压测, 测试方式及结果:

• 第一轮： 每秒大概 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 官方博客