skywalking-2：skywalking3.2.6性能压测与测试报告(历史总结)

(1).目的

1.评估在业务服务的极致qps下，skywalking是否对业务有影响。这个是最重要的。

2.压测skywalking-collector单节点QPS极限。

结论：

A.对于目的1：

影响很小，符合官方说明。

B.对于目的2：

很难压到，因为资源限制，没办法发出那么多并发。从预先评估（基于架构），官方作者回复，实际压测结果来看，目前配置，skywalking-collector生产环境单节点10K+没有问题，公允范围估测10K~20K.

官方issue参考：https://github.com/apache/incubator-skywalking/issues/1596#issuecomment-416481558

ab 10并发，1000请求，日志记录率100%。但是如果更高，受限于资源，就不准了。实际是做过多组的，如100并发50万请求等等，但是没必要列了。

整体来看评估的话，skywalking-collector单节点支持10K+qps，日志记录率80%左右应该还是可以的。但是这个只是基于N组测试的预估，具体如何线上观察。

但是可以确认的是，4台es, 3台skywalking-collector是足够新闻赚使用了，在不影响业务的前提下，区别在于链路日志记录率，这个线上观察。继续压测意义不大。

C.线上skywalking-collector的jvm参数使用：

-server -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xms6000M -Xmx6000M -XX:+UseG1GC -XX:LargePageSizeInBytes=128m

(2).测试版本与最终结果

skywalking与elasticsearch版本：skywalking-stable-3.2.6， elasticsearch5.6.8

实际上做了很多组压测，skywalking-collector的qps单节点10K+没有问题。

需要说明，后续的skywalking在很多方面对性能做了大幅优化，性能并不是问题，当然我们线上启用时要特别注意采样比例。

(3).java测试工程

专用branch：https://github.com/hepyu/bird

由于测试资源有限（都要开6G，和线上保持一致），只是用lbsweb->lbsservice这个链路。

(4).测试工程的jvm相关参数裁定标准

以我们线上业务的jvm参数未基准，如下例：

/app/3rd/jdk/default/bin/java -Djava.util.logging.config.file=/app/xxx/ne-client/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -XX:PermSize=64M -XX:MaxPermSize=128m -Xms6000m -Xmx6000m -Duser.timezone=Asia/Shanghai -Djava.endorsed.dirs=/app/xxx/ne-client/endorsed -classpath /app/xxx/ne-client/bin/bootstrap.jar:/app/xxx/ne-client/bin/tomcat-juli.jar -Dcatalina.base=/app/xxx/ne-client -Dcatalina.home=/app/xxx/ne-client -Djava.io.tmpdir=/app/xxx/ne-client/temp org.apache.catalina.startup.Bootstrap start

主要参数：

-XX:PermSize=64M -XX:MaxPermSize=128m -Xms6000m -Xmx6000m

(5).机器配置

4台es, 3台collector, lbsservice在collector002, lbsweb在collector003。测试的时候只启用一个collector节点collector001。002,003分配给motan RPC和http web。

7台机器都是4核8G。

JDK使用1.8。

(6).benchmark测试与报告

为了保证各个case的结果可比性，每次case执行前都需要依次执行：

a.清空es数据。curl -XDELETE http://xxx.xx.xx.22:9200/*

b.重启collector，jstat -gcutil好计算。

c.重启lbsservice和lbsweb，jstat -gcutil好计算。

(6.1).第一组

100个并发，1,000,000个请求。

对应产生100万个/lbs/currentLocation/{userId} ，和100万个com.xxx.lbs.service.LBSService.currentLocation(long) 。

目的：主要是验证业务系统在极端并发情况下，skywalking是否对业务系统有大的影响。

做法：http web服务压满。

结论：可以认为无影响，只是链路日志丢失的比率会高至50%。

测试报告包含机器和实例。

(*1).有细小差别：ab测试的发起方在trace-es001上，从实际来看，这个差别可以忽略。具体配置参见本文(3).不需要

(*2).lbsweb(提供http服务)和lbsservice(使用motan提供rpc服务)都是基于springboot的两个很简单的服务，user请求-> lbsweb -> lbsservice(直接返回一个字符串)。

这个链路很简单：/lbs/currentLocation/{userId} -> com.xxx.lbs.service.LBSService.currentLocation(long)

(*3).springboot参数server.tomcat.max-threads默认值200，需要说明这里调整这个值只是为了压测，而且也过小，并不意味着可以直接拿到线上，是有很大区别的。

(*6.1.1)：借用一台es001作为abtest发起者，实际来看，对测试影响不大。我不想再改集群规模腾机器。只有这一处做了折衷。

(*6.1.2)：这个不好算，得统计es中数据，需要了解skywalking在es中存储拓扑。可以大致估算。

ab -c 100 -n 1000000 http://xxx.xx.xx.xx:9082/lbs/currentLocation/19

详细报告参见：

https://kdocs.cn/l/cdUUitoEIvbx

[金山文档] skywalking-2：skywalking3.2.6性能压测与测试报告(历史总结).doc

(6.2).第二组

目的：找到链路日志记录率90%以上的点。

做法：ab定义不同并发和请求。

结论：

ab 10并发，1000请求，日志记录率100%。但是如果更高，受限于资源，就不准了。实际是做过多组的，如100并发50万请求等等，但是没必要列了。

整体来看评估的话，skywalking-collector单节点支持10K+qps，日志记录率80%左右应该还是可以的。但是这个只是基于N组测试的预估，具体如何线上观察。

但是可以确认的是，4台es, 3台skywalking-collector是足够新闻赚使用了，在不影响业务的前提下，区别在于链路日志记录率，这个线上观察。继续压测意义不大。

测试报告包含机器和实例。

(*1).有细小差别：ab测试的发起方在trace-es001上，从实际来看，这个差别可以忽略。具体配置参见本文(3).

(*2).lbsweb(提供http服务)和lbsservice(使用motan提供rpc服务)都是基于springboot的两个很简单的服务，user请求-> lbsweb -> lbsservice(直接返回一个字符串)。

这个链路很简单：/lbs/currentLocation/{userId} -> com.xxx.lbs.service.LBSService.currentLocation(long)

(*3).springboot参数server.tomcat.max-threads默认值200，需要说明这里调整这个值只是为了压测，并不意味着可以直接拿到线上，是有很大区别的。

(*4).这个不好算，skywalking-collector没有配置打印access的log，只能通过ab qps去大致评估。

注：

实际上做了很多组，skywalking-collector的qps单节点10K+没有问题。