全链路压测工具怎么用（网络压测工具）

本篇文章给大家谈谈全链路压测工具怎么用，以及网络压测工具对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享全链路压测工具怎么用的知识，其中也会对网络压测工具进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、压测工具JMeter的使用

• 2、全链路压测流量模型

• 3、提升cpu使用率

• 4、linux安装全链路追踪工具skywalking8.0

• 5、全链路Controller压测负载均衡

• 
  

压测工具JMeter的使用

性能压测工具，在我们项目开发过程中肯定免不了要经常使用，来检测我们完成的接口或者整体服务的抗压水平。Apache提供了个 ab 命令，可以进行压测功能，只不过功能相对简单，有时候很难满足我们的测试需求。

所以，这里介绍下Apache的另一款压测工具 JMeter，它是Apache组织开发的开源项目，设计之初是用于做性能测试的，同时它在实现对各种接口的调用方 面做的比较成熟，因此，常被用做接口功能测试和性能测试。

本次压测模拟的流程是：请求先访问登录接口，成功后通过返回信息拿到用户ID，再将用户ID作为参数访问商品下单的接口。压力测试规则是每秒1000的并发请求，执行1次，也就是执行1s。

PS：下方涉及到的三个变量 NAME、PASSWORD、USER_ID 它们是需要用 {} 来包裹的，我下边写错了，写成了 () 包裹的了。哈哈，我实在是懒得挨个截图改了，在这里说明下，明白原理就好

全链路压测流量模型

现在全链路越来越火，各大厂商也纷纷推出了自己的全链路压测测试方案。特别是针对全链路压测流量模型，各家方案都有所不同。最近我看了一些这方面的资料，有一些感悟。分享给大家。

全链路压测流量模型的梳理呢，这里就先不讲了，各家公司自有司情在。因为主要是全链路压测模型的实现，其实实现也对应了流量模型的梳理结果。

业界常用的三种方一种：是基于业务模型的实现，一种是基于真实流量的录制回放，最后一种是灰度分流。

这个是一种比较常用的方式。首先要对公司业务模型进行梳理，也就是说对公司的业务链路进行梳理。这里的业务链路可能会比较复杂，不是像很多案例中到的了就非常流行畅的一条链路，中间很有可能会出现各种各样的支路。如果图图形化展示的话，某一条链路应该就是一个树形结构。树形结构的开始是用户的入口页一般就是入口页面的登陆，或者说是首页接口。树形结构的右侧是用户的出口，这里根据业务模型不同，用户的出口会非常的多，所以大多数来时候来讲，这就是一个分叉的树形结构。

要对这样的流量模型进行实现。是比较困难的。首先要梳理出这样的业务模型，就不太容易，再加上接口的相互调用啊，数据之间的相互依赖又可能是复杂程度增加一个量级。所以一般的实现方式就是做归拢。将比较复杂的树形结构简单化，或者干脆将以个业务联络分解成n个列有链路。然后分别实现。最终将流量汇聚，就变成了整个业务链路的流量模型实现。

在业务模型实现这个方向，各家都有不同的实现方式啊，基本上就分为工具以及脚本实现。我自己不怎么用工具做过接口的性能测试，全都是使用java和groovy脚本去实现的。首先，我会实现一个基于接口的业务测试框架，将每一个接口封装成一个方法。接口的参数即是这个方法的参数。然后将每一个用户封装成一个对象。将用户的各种信息变成这个对象的属性。然后用户在请求不同的接口的时候对用户的属性进行赋值这样就达到了一个参数传递的目的。然后通过调用不同的方法，我们就可以实现对不同接口的请求。通过控制参数或者说接口请求的频率，我们就可以达到控制当前用户。在整个业务链的走向。

基于流量录制和回放，这个是最容易实现的方式。也是最容易贴近真实情况的方式。哦，我接触到的主要有一个回放模型，就是用golang语言写的goreply。go语言的性能是非常好的，用于性能测试足够满足用户的需求。大多数公司都会选择在原生引擎的基础上做一些封装。然后对对业务进行一些兼容，最主要的还是适配流量来源。通常流量的来源是通过日志文件来获取的，但是我看行业内也有通过一些固定的流量存储分析引擎去完成。这里的技术我不是太熟，也就不多分享啦。

我觉得基于流量录制回放这种模式有一个比较难以解决的问题：流量的不可见性。一般来说，录制流量会非常大。介于几十万上百万之间。这么规模大的流量，是很难对他进行可视化的。常遇到的一个问题，就是对于一些请求量非常小的接口。录制的时候可能会录丢。还有一种就是录制流量的时间范围不会太广。那么录制出来的流量文件只能反映录制时的流量模型，并不能反映其他录制时间段的流量模型。如果某个服务的流量是根据时间变化的。那么就需要对多个时间段都录制流量，然后进行合并。由于流量的不可见性，所以对流量的模型进行分析，就会显得比较麻烦。

这是我在某个会议上看到大佬分享的一个方案。灰度大家听的可能比较多的是灰度发布。就是将服务或者app更新范围限制在某些一批人，或者说某个地理范围。这里讲的灰度分流，其实核心上差不多，就是将线上的一部分流量转到某些机器上。以实现对这些机器所在服务的一些压测。这种方案。基于线上流量完成，所以几乎不需要测试。投入过多的资源进行开发实现。这种方案有点儿基于业务模型和基于流量录制取了一个中间态。既能保证流量的真实有效性。又可以避免开发测试脚本带来的负担。

这种方式对于公司的架构，主或者说是分流的实现来说，技术难度是比较高的。因为他用的全都是用户的真实数据，所以一旦出现问题的话，这个问题影响范围不太可控，而且比较严重。对于接收灰度分流流量的机器来说，压测流量完全真实。但是他也无法避免基于流量录制，回放同样的问题。就是流量的不可见性以及流量与时间可能存在于一个关联关系并不是线性的。甚至这一点流量的灰度分流还不如流量的录制与回放。我想这也是。我身边接触到的公司，都没有采用这种方案的原因吧。

提升cpu使用率

压测工具一般在性能压测过程中用于对被压的系统产生压力，压测工具的发压能力的大小是影响一个性能工程中压测的成本以及效率相关的重要因素。因此对于一款压测工具，如何优化其发压能力是在开发压测工具是需要重点考虑的内容。

压测工具的工作流程如图所示：

一个压测工具的运行周期为：

那么在优化发压能力的cpu使用时，就需要从发压的上下文，以及在发压执行过程中去考虑。在发压的上文主要做的事就是要读入或者生成执行发压操作时需要的数据，那么上文优化需要考虑的就是尽可能快地把需要地数据给到cpu（cpu缓存读，内存读，外部缓存读等），如果数据是执行过程中生成的，则生成数据的操作不能太耗费cpu。在发压的操作完成的下文要做的事是将操作的采样数据进行收集汇总，那么下文优化时考虑如何快速的收集采样数据，如果时需要实时汇总数据则指标汇总的操做不能占用太多发压操作的cpu。在发压过程中时，为了保证发压的操作尽可能地占用cpu，可以考虑为其分配独占的cpu，避免其他的进程间争抢cpu。

cpu 使用率相关的性能指标：

cpu的总体使用率表示为：除了空闲时间外的其他时间占总 CPU 时间的百分比，

一般在分析cpu使用情况时主要从以下几个方面进行考虑：

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，可以通过查看 /proc/softirqs 来观察软中断的运行情况。

上面介绍了从应用进程角度优化cpu的整体思路。那从cpu的角度出发，具体优化cpu的方法有哪些呢？

在当今"冯诺依曼"体系架构下，cpu 作为计算机的核心计算单元，除了需要执行计算逻辑之外，cpu还需要从内存读取或者写出数据，所以cpu优化的整体思路有：优化本身的计算逻辑，以及提高cpu 读入和写出数据的速度。

从优化本身的逻辑的角度，即应用程序角度cpu的优化的思路时： 排除所有不必要的工作，只保留最核心的逻辑。比如减少循环的层次、减少递归、减少动态内存分配等等。具体的优化方法有：

在提高cpu 的使用方面从系统的角度出发，一方面要充分利用cpu缓存的本地性，加速缓存的访问；另一方面要控制进程的cpu使用情况，减少进程间的相互影响。具体常见的优化方法有：

linux安装全链路追踪工具skywalking8.0

SkyWalking是一个针对分布式系统的APM（应用性能监控）系统全链路压测工具怎么用，特别针对微服务、cloud native和容器化架构全链路压测工具怎么用，其核心是个分布式追踪系统。它通过探针自动收集所需的指标，且基于探针技术对应用零侵入零耦合。通过这些调用链路以及指标，SkyWalking APM会感知应用间关系和服务间关系，并进行相应的指标统计。

解压后，进入目录，默认自带了agent，这个是用来追踪java项目的。全链路压测工具怎么用我因为是用来追踪php项目，所以这个用不上，如果要追踪php项目，需要另外安装php的agent，请查看我另外一篇文章( linux安装sky-php-agent )

bin里面是启动文件

config目录里面是配置文件

webapp目录里面是UI界面项目文件和配置文件

默认情况下，只需要更改一下 config/application.yml文件

默认的restHost和gRPCHost的IP为0.0.0.0，我这里改成我这边内网的IP。这里要注意一下，一旦改了IP，就只能用这个IP，比如我这里改成了内网IP，那么用127.0.0.1都不能访问。

如果需要更改UI界面访问的端口，可以修改 webapp/webapp.yml，里面配置文件很简单

注意一下，如果要想能够让受控端访问到skywalking服务，那么必须将12800端口对受控端服务器打开。WEB界面的端口，我这里是8081，大家可以改成自己需要的端口。

变更完配置后，就可以进去bin目录下，运行 startup.sh ，服务就会启动。然后通过http://服务器ip:8081进行界面访问。

受控端如果也启动了的话，这个时候，界面里就自动会出现数据了。

emmmm.....这里有个坑，默认情况下，打开界面什么数据都看不到，这个需要点击右上角的“自动”按钮，让按钮变成蓝色，这个时候就会有数据出现了。

如果还是没有出现数据，那就检查受控端服务是不是已经启动了，或者去看一下logs目录下的日志。如果受控端连接服务端出现错误，就看skywalking-oap-server.log全链路压测工具怎么用；如果受控端一切正常，界面数据还是不显示，就看webapp.log

我在安装的时候，使用startup.sh启动文件，又遇到一个坑。这个启动文件，无论中间是不是有报错，都会提示启动成功。而且因为没有停止的命令，如果重复运行startup.sh，日志里会提示端口占用。这个时候，需要使用命令先查看占用端口的进程，然后杀掉进程，再重新运营启动文件才可以。

全链路Controller压测负载均衡

LoadRunner有两种方式可以模拟用户：一是线程;二是进程。一般情况下我们进程方式来模拟虚拟用户，即如果我们设置10个虚拟用户，那么在后台会生成10进程，进程名为mmdrv.exe，来模拟10个虚拟用户，每个进程相当于一个虚拟用户在操作服务器。

需要多少台负载机的算法是这样计算的，首先需要计算出所有用于模拟虚拟用户进程所消耗的内存量。

● 总的内存=N*mmdrv.exe(所消耗的内存)

● N表示虚拟用户数。

计算每台负载机最多可以使用内存，所谓负载机就是我们说测试机，用于产生mmdrv.exe进程的测试机。

将总的所需要的内存除以每台负载机最多可以使用的内存，即可以计算出一共需要多少台负载机。

负载机工作原理：

控制器与负载机是通过lr_bridge.exe这个进程来实现的，通过这个进程来让两台机器进行通讯。

当有多台测试机时，我们希望将所有的请求平均的分配到不同的负载机，我们把这个过程称之为负载均衡。

只能在百分比模型才可以设置负载均衡，普通的场景模式下是无法设置负载均衡的。 关于全链路压测工具怎么用和网络压测工具的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 全链路压测工具怎么用的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于网络压测工具、全链路压测工具怎么用的信息别忘了在本站进行查找喔。