下一个 release 准备小长假后就要 go-live 。全部的測试 case 都 cover 过了。但还未进行过压力測试，有点不放心，刚好过节期间家人都回家去了，假期最终能够抽点时间压測一把。
Apache ab 压測
之前用过一些压力測试工具比方 loadrunner。 Jmeter，感觉都太重，想要使用不是软件须要注冊就是使用起来非常不得心应手，这次灵光一动。想到直接使用 ab ＋ OneAPM 进行測试，ab 的全称是 ApacheBench , 是 apache http server 自带的一个測试工具。专门用于 HTTP Server 的 benchmark testing，能够同一时候模拟多个并发请求。
公司的开发者也在用它作一些測试，看起来也不错，非常easy，也非常easy使用。能够对你的 Web 网站进行压力測试，非常小。使用起来非常easy。
假设你已经安装了 apache。那么在 <apache>/bin 文件夹就能找到 ab，输入ap –help `, 里面简单几个选项细致读一下，非常快就能上手进行測试。
官方使用文档：https://httpd.apache.org/docs/2.4/programs/ab.html
OneAPM
这个就不用多说了，性能监控软件，怎样使用參看下官网的 guide，我分别在不同的平台上都试过接入 OneAPM，比方 node.js。ruby，php，java，使用起来挺简单方便的。
| 环境： | 内网測试server |
| 语言： | Ruby |
| Framework： | ror |
| 数据库： | MongoDB |
总共进行了两轮压測, 測试方式及结果:
- 第一轮： 每秒大概 30 个并发, 单页面訪问
- 第二轮：并发量每秒提升到 100。分别訪问 4 个主页面
使用 ab 进行測试的方式：
ab -n 1000 -c 30 <your url>
-n 是指总的 request 数量。-c 是指同一时间并发量
下面是在加入了OneAPM Ruby agent之后，使用 apache ab 压測结果。
整体拓扑
OneAPM 通过拓扑图来展示应用的端到端调用关系、应用server与数据库、外部 服务的调用关系以及应用之间的调用关系。
同一时候。通过在拓扑图中将对应模块标记成不同颜色。
由于仅仅是压測，就没有在測试环境部署相关的后台任务。也没做集群以及 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 官方博客