1、压测环境

1.7服务器、1.7charging-api服务、1.7apm服务

2、压测方法

压测工具：apache bench
压测接口：http://192.168.*.*:8089/test-api/rest-api

压测步骤：分为三种情况压测：接入apm之前；接入apm之后；中途把apm服务停掉(模拟apm服务不可用情况)，每种情况下，都以1000的并发量(由于是同一台机器上的并发，模拟太多并发反而上下文切换频繁导致达不到真正的并发),请求50w的总量(ab -n 500000 -c 1000 http://192.168.*.*:8089/test-api/rest-api),分别观察服务所占cpu和内存的情况、jvm监控、ab压测结果。

3、压测结果对比

以下是三种压测情况的对比图：

apm	进程id	linux	jvm	ab
接入前	145252
接入后	172542
中断	48089

4、压测结论

• 由于1.7环境上有很多进程干扰，而且三种方式的压测时间不同，导致干扰也不同，所以此次压测，有几个指标没有参考意义：被压测的服务性能、ab压测接口性能、ab压测总体用时，每次请求耗时。
  又因为被压测服务，在不同时段内，有可能还会有不同的请求被接入，所以进程的资源使用：cpu、jvm内存，也只能做大概的参考。
• liux列是分别在压测到40w的时候截出来的对比图，从这一列图中我们可以看出进程所在的cpu基本是一样的，其实在压的过程中我从关到尾观察了资源的占用情况，其中三种情况下cpu占用最高都是百分之6百多，频繁都在5百到6百之间，包括VIRT和RES都是不相上下的(这列偷懒没有用工具全程监控并记录)。所以从这一列我们可以看出：接入apm的服务，不会出现cpu或内存额外的增高。
• jvm列是在开始压测到结束的jvm监控过程，从cpu指标看，大部分是在40%以下30%以上，1.7服务有16个核，那么就是占总cpu的百分之5百多，堆内存也是最高也都达到400MB,接入前比接入后堆内存使用多了9MB左右，再看实时线程比没接入之前多了9个。
• 从ab指标看，三种情况请求失败数都是0，说明每种情况50w的量都能达到charging-api服务，由于环境在不段变化，三种情况出的其它指标结果没有可比性，如总体用时、TPR、请求耗时分布。
  结论：结合apm监控分析，每分钟并发量最高达到800，apm接入后，不影响业务功能；增加了10个左右的活动线程；内存使用会增加2%左右。