前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >skywalking-2:skywalking3.2.6性能压测与测试报告(历史总结)

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

作者头像
千里行走
发布2020-07-31 16:35:25
3.4K0
发布2020-07-31 16:35:25
举报
文章被收录于专栏:千里行走

(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+没有问题。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-07-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 千里行走 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
Elasticsearch Service
腾讯云 Elasticsearch Service(ES)是云端全托管海量数据检索分析服务,拥有高性能自研内核,集成X-Pack。ES 支持通过自治索引、存算分离、集群巡检等特性轻松管理集群,也支持免运维、自动弹性、按需使用的 Serverless 模式。使用 ES 您可以高效构建信息检索、日志分析、运维监控等服务,它独特的向量检索还可助您构建基于语义、图像的AI深度应用。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档