专栏首页千里行走skywalking-2:skywalking3.2.6性能压测与测试报告(历史总结)

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,需要说明这里调整这个值只是为了压测,而且也过小,并不意味着可以直接拿到线上,是有很大区别的。

机器配置

说明

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

本文分享自微信公众号 - 千里行走(a_thousands_of_miles),作者:千里行走

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-07-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • skywalking-1:skywalking3.2.6生产级部署(历史总结)

    Skywalking3.2.6是很老的版本了,18年8月左右的最新stable版本,进行总结纯粹出于方法论和过程论的总结,以及历史沉淀。

    千里行走
  • 用SkyWalking做分布式追踪和应用性能监控系统

    【转载请注明出处】:https://cloud.tencent.com/developer/article/1655702

    后端老鸟
  • Skywalking微服务监控分析

    微服务框架落地后,分布式部署架构带来的问题就会迅速凸显出来。服务之间的相互调用过程中,如果业务出现错误或者异常,如何快速定位问题?如何跟踪业务调用链路?如何分析...

    yuanyi928
  • APM 原理与框架选型

    随着微服务架构的流行,一次请求往往需要涉及到多个服务,因此服务性能监控和排查就变得更复杂:

    JadePeng
  • 赠书:分布式系统中的监控怎么做?

    导读:本文摘自于SkyWalking创始人吴晟撰写的《Apache SkyWalking实战》一书,详细讲述了SkyWalking的架构设计与优势。

    程序猿DD
  • SkyWalking - 实现微服务监控告警

    SkyWalking 告警功能是在6.x版本新增的,其核心由一组规则驱动,这些规则定义在config/alarm-settings.yml文件中。 告警规则的定...

    端碗吹水
  • skywalking内存泄露排查

    最近写的关于dubbo内存泄露稍微复杂了一点,很多人表示看不明白,想到之前遇到的比较简单的内存泄露问题,更容易入门,于是拿出来分享一下。

    龟仙老人
  • SkyWalking链路追踪系统-告警篇

    Skywalking发送告警的基本原理是每隔一段时间轮询skywalking-oap收集到的链路追踪的数据,再根据所配置的告警规则(如服务响应时间、服务响应时间...

    仙人技术
  • 分布式链路追踪 Skywalking:告警和度量架构设计

    SkyWalking 是一个开源 APM 系统,包括针对 Cloud Native 体系结构中的分布式系统的监视、跟踪、诊断功能。核心功能如下:

    用户6969969

扫码关注云+社区

领取腾讯云代金券