(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,需要说明这里调整这个值只是为了压测,而且也过小,并不意味着可以直接拿到线上,是有很大区别的。
机器配置 | 说明 | 服务(*2) | jvm | springbootserver.tomcat.max-threads参数 | |
---|---|---|---|---|---|
基准 | 参见(3) | 各个配置和线上保持一致。(*1)由于使用的是jdk1.8, PermSizeMaxPermSize不生效。 | lbsservice单节点 | -Xms6000m -Xmx6000m | 默认值200(*3) |
lbsweb单节点 | -Xms6000m -Xmx6000m | 默认值200 | |||
skywalking-collector单节点 | -Xms6000M -Xmx6000M | 默认值200 | |||
case1 | 同基准 | jvm配置metaspace | 同基准 | -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xms6000M -Xmx6000M | 默认值200 |
case2 | 同基准 | jvm配置metaspace | 沒有skywalking-collector节点 | -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xms6000M -Xmx6000M | 默认值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,需要说明这里调整这个值只是为了压测,并不意味着可以直接拿到线上,是有很大区别的。
机器配置 | 说明 | 服务(*2) | jvm | springbootserver.tomcat.max-threads参数 | ||
---|---|---|---|---|---|---|
基准 | 参见(3) | 10个并发1000个请求 | 各个配置和线上保持一致。(*1) | lbsservice单节点 | -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xms6000M -Xmx6000M | 默认值200(*3) |
lbsweb单节点 | -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xms6000M -Xmx6000M | 默认值200 | ||||
skywalking-collector单节点 | -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xms6000M -Xmx6000M | 默认值200 | ||||
case1 | 同基准 | 10个并发10000个请求 | 同基准 | 同基准 | 同基准 | 默认值200 |
(*4).这个不好算,skywalking-collector没有配置打印access的log,只能通过ab qps去大致评估。
链路日志记录率 | ab结果 | skywalking-collector结果 | ||
---|---|---|---|---|
/lbs/currentLocation/{userId}记录数/lbs/currentLocation/{userId}记录率 | com.xxx.lbs.service.LBSService.currentLocation(long) 记录数com.xxx.lbs.service.LBSService.currentLocation(long) 记录率 | ab qps | skywalking-collector qps(*4) | |
基准 | 1000100% | 1000100% | 6981.19(不准,只可参考) | around 6981.19*2(不准,只可参考) |
case1 | 774077.4% | 762076.2% | 7344.19(不准,只可参考) | around 7344.19*2(不准,只可参考) |
注:
实际上做了很多组,skywalking-collector的qps单节点10K+没有问题。