Hale2023-05-26 来自广东老师好，请问，使用agent是怎么判断jemter压测结束各个状态的？这块不理解作者回复: 你好，我们可以回顾一下文中的状态变换表格和状态机，其中每个状态都有成功的条件和失败的条件，具体状态是保存在数据库中的，我们可以通过轮询这一状态，根据结果决定是否执行后续步骤。整个逻辑都是状态机管理的，Agent只负责执行指令。 举个例子，当用户触发一次压测，系统会同时建立三个任务：配置、执行和运行。配置任务在成功完成后会将状态置为BOOTED，失败则置为BOOTERROR。与此同时，执行任务在不断轮询状态，一旦轮询到状态为BOOTED，立刻执行触发逻辑，如果轮询到状态为BOOTERROR，则终止，并取消后续运行任务。运行任务的原理也是一样的。最后，有一个收集任务做兜底清理工作。 值得注意的是，平台的视角是压测的状态管理，并非局限于JMeter的工作状态。
天启2023-02-20 来自上海老师我又有问题啦，就是如果在每个压测节点部署一个压测的agent程序，假设我理解为这个是个javaweb应用程序吧，这样就相当于压测任务开始的时候一个虚拟机上有2个java进程一个是这个javaweb程序，一个是jmeter的java进程，那么会不会存在压测的时候这个jmeter进程挤占这个javaweb程序的资源，导致这个代理程序崩溃，这种有什么好办法吗，还是说2个进程都搞成容器化，可以资源独立作者回复: 你好，这个agent是一个用Java编写的轻量级Lib，使用Netty与服务器进行通信，自身持有的资源很少。此外，agent所做的工作是低频的，例如：每轮测试中的同一类文件只需要传输一次，各个状态变换时下发的指令也是有限的。唯一比较消耗资源的是结果文件的聚合（消耗CPU）和回传（消耗带宽），但这一操作是在压测结束后异步进行的，因此资源消耗是错时的。 另外，agent的JVM进程和JMeter的JVM进程是隔离的，两者都有自己的堆大小和栈大小控制，只要相加不超过总的内存大小，一般不会互相影响。
- 天启2023-02-02 来自上海老师问下，最近在使用阿里pts工具的时候，发现pts有个叫采样日志率的概念，可以看到压测过程中某些请求的详细返回信息请求信息，感觉对压测问题分析挺有用的，但是参考jmeter的实现看了一圈，我想到相对2种实现方式：1.修改jmeter的properties文件，让jtl文件中展示更多的信息展示，但是这个有很多的缺点需要消耗压测节点大量的磁盘空间，且这个结果是在压测结束后才能进行处理2.第二种方式是自己写一个backendListener插件，在钩子函数中发送sampleresult，但是这个有个难点，就是样本总数在运行时无法确定，不太好实现日志采样率。所以想问下老师这块你们的压测平台有去实现吗，想借鉴下思路
作者回复: 你好，你的问题关注的是如何获取压测流量的响应信息，我们的压测平台是通过对接JMeter的“查看结果树”控件来实现的，激活“Save Response Data”，同时勾选“仅错误日志”（一般来说，只有排障时才需要关注详细的响应信息），生成的结果文件以固定的文件名保存，压测平台的服务器会在压测后统一回传至文件存储组件供下载，默认保存7天。当然，由于查看结果树的结果文件是以流的形式实时构建的，因此我们也提供了实时查看的功能，压测平台服务器提供了后端接口，将文件内容实时读取出来，前端得到结果后展示在页面上。 查看结果树本身提供了设置响应数据最大展示大小，以及最大文档大小等参数，基于这些考虑，我们并不需要以抽样的方式获得数据。
- 天启2022-09-21 来自上海老师你好，我想问下通过部署agent的方式来规避master-salve的痛点的话，压测机的启动方式是以jmeter-server方式的吗，还是说是用agent,动态的进行命令行方式jmeter -n xxxx动态启动压测？
作者回复: 你好，启动方式是后者。我们完全放弃了JMeter的分布式执行策略，因此也就不再使用jmeter-server的启动方式，所有JMeter节点都视为是Master由平台统一调度。
共 3 条评论 
菜蜗牛2022-05-25老师，您好， 请问您的压测平台是否是开源的呢？是的话，是否可以贴一下源码地址作者回复: 你好，我确实早有开源的计划，但因为一些限制暂时无法达成，一旦能够开源，我会及时更新，感谢你的关注
追风筝的人2022-05-17老师 你知道客户端使用mc 工具， 服务端是3个节点的minio集群 怎样做对服务端的上传 下载 性能测试？ MC这个工具怎么指定并发数作者回复: 你好，mc工具我不太熟悉，无法提供专业的指导，非常抱歉
林林总总01072021-11-18老师，想问下关于线程数与TPS/QPS动态设置的时候，这里面的关系应该是怎样的？比如，执行java -jar /lib/bshclient.jar localhost 9000 update.bsh <qps>，这里面只有调整QPS/TPS,但是没有线程数的调整，是不是说只需要调整<qps>，不管线程数的调整？我看到配置集功能里面的用例也有总线程数的参数项，具体执行测试的时候这个值应该怎么去调整呢作者回复: 你好，如果需要调节QPS，线程数一般适当设大点就行了（线程数是固定值），如果线程数设的太小，达不到目标QPS，那么调节也就没意义了。当然，也不要把线程数设的太夸张，一方面压测资源不一定够，另一方面JMeter是通过间隔抛弃请求达到控制QPS的效果的，线程数太大可能会造成抖动。
- ask0012021-07-19谢谢老师之前问题的答复！老师我现在还有个疑问是看jmeter自带的InfluxdbBackendListenerClient逻辑是：BackendListener会把SampleResult丢到BlockingQueue中，BackendListener也会起一个线程从BlockingQueue中取SampleResult丢给BackendListenerClient处理。InfluxdbBackendListenerClient处理SampleResult的逻辑是最终把SampleResult加到DescriptiveStatistics中，InfluxdbBackendListenerClient会起一个定时线程池，定时利用DescriptiveStatistics先计算一下在定时时间间隔段（默认值5秒）采样到的SampleResult的统计值（比如平均响应时间、总的sample、5秒内95线等）发给influxdb。所以InfluxdbBackendListenerClient其实入influxdb的值是在定时间隔段内计算后的值。老师想问下如果是多节点每个节点都是上报给influxdb，如果用jmeter自带的InfluxdbBackendListenerClient是不是不合适？还是说自己写一个InfluxdbBackendListenerClient，把原始的采样结果入influxdb,这样方便influxdb 取数据加工(根据具体指标进行求和或求平均值等),如果是原始的采样结果入influxdb我觉得jmeter每次采样数据发influxdb会是瓶颈，影响压力机资源，同时因为用的社区版influxdb，TPS大的化influxdb也可能会是瓶颈？展开
作者回复: 为你的认真细致点赞！我说下我个人的理解。 对于实时数据，一般来说我们其实只需要观察一个宏观的指标概要，判断压测时的大致状况，有无风险等。而对于非实时数据，则需要计算出精确的指标（如99线等），因为我们要输出结论供详细分析和其他决策参考（限流等）。 这是压测平台将数据进行冷热分离最原始的初衷，越精确的结果，必然会带来越昂贵的计算量和资源消耗，我相信JMeter的InfluxdbBackendListener的这种处理方式，肯定也有这方面的考量。 原始的采样数据，在生成的JTL文件中都有，精确到了每个请求，我们在压测后统一回传服务器做异步处理，不存在资源瓶颈问题，用户最多只需等待几分钟。
- ask0012021-07-15问下基于获取和展示实时数据（热数据）这块，如果要用多台压测机的化也是用master-slave 这种模式吗？这种模式压测过程中slave会把采样结果传回master机器，master机器统一计算后再入influxdb（比如5秒内的所有采样结果计算下在发送到influxdb），这种模式如果tps大的化，master是不是还会有瓶颈，还是说没用master-slave这种模式的？
作者回复: 不是传统的master-slave模式。 实时数据的采样，是每个slave在压测时直接将数据上报至InfluxDB的。每一轮压测，平台都会生成一个唯一的triggerId，所有slave上报数据时均带上值为这个triggerId的TAG，以便InfluxDB聚合。 master则是直接从InfluxDB中取出数据，进行一定的加工（根据具体指标进行求和或求平均值等），再推送数据展示到前端。 显然，master的计算量不大（而且都是用了InfluxDB自带的聚合方法），所以瓶颈一般不会出现在master。反倒是slave在上报数据时，如果TPS很高可能会出现瓶颈，关于这一点可以看一下JMeter的InfluxdbBackendListener的实现，简单说，数据上报是通过消息队列异步进行的，且这个队列是有长度上限的（可以设置），通过这种方式避免过多的影响slave的压测资源消耗。