由于工作的原因,或者说我们之前内部监控设计和实现有点不满足现有的研发需求,所以调研了一下大众点评开源出来的cat这一套监控系统。
今天我们就来实验一把,cat的客户端埋点在我们的程序流程中上报数据到cat的服务端这个流程对我们程序性能的影响。
测试工具
Jmeter
测试环境
Cat部署在内网192.168.84.27,内存6G,CPU 4核
单台cat和单台dubbo
代码
原接口代码
public String kongjiekou() { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } JSONObject object = new JSONObject(); object.put("msg", "这是一个空接口"); return object.toJSONString(); }
埋1个点接口代码
public String kongjiekou() { Transaction transaction = Cat.newTransaction("inner", "kongjiekou"); try { Cat.logMetricForCount("kongjiekou");//埋一个点 Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); Cat.logError(e); } finally { transaction.complete(); } JSONObject object = new JSONObject(); object.put("msg", "这是一个空接口"); return object.toJSONString(); }
埋100个点接口代码
public String kongjiekou() { Transaction transaction = Cat.newTransaction("inner", "kongjiekou"); try { for (int i = 0; i < 100; i++) { Cat.logMetricForCount("kongjiekou"+i);//埋100个点 } Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); Cat.logError(e); } finally { transaction.complete(); } JSONObject object = new JSONObject(); object.put("msg", "这是一个空接口"); return object.toJSONString(); }
统计数据
Dubbo中的kongjiekou接口原先并发效率
并发量(1s) |
平均耗时(ms) |
耗时中位数(ms) |
错误率 |
100 |
1036 |
1023 |
0.00% |
500 |
2009 |
1955 |
0.00% |
1000 |
3069 |
3032 |
0.00% |
接入cat客户端埋1个点之后
并发量(1s) |
平均耗时(ms) |
耗时中位数(ms) |
错误率 |
100 |
1061 |
1040 |
0.00% |
500 |
2154 |
2085 |
0.00% |
1000 |
3352 |
2955 |
0.00% |
接入cat客户端埋100个点之后
并发量(1s) |
平均耗时(ms) |
耗时中位数(ms) |
错误率 |
100 |
1143 |
1024 |
0.00% |
500 |
2333 |
2285 |
0.00% |
1000 |
3435 |
2920 |
0.00% |
并且在多次性能测试过程中,内存占用情况并没有明显升高,CPU也是正常的执行时长高到正常值,执行后恢复,每次的内存和CPU峰值都相差无几。由于研发内网的带宽本身就极不稳定,所以带宽指标这里先不做判定。
总结
从以上结果得出初步结论,cat的监控埋点对被监控程序本身的性能的影响可忽略不计。