由于工作的原因，或者说我们之前内部监控设计和实现有点不满足现有的研发需求，所以调研了一下大众点评开源出来的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的监控埋点对被监控程序本身的性能的影响可忽略不计。