之前写了两篇文章分享自己对几种性能测试框架的测试：性能测试框架对比初探、性能框架哪家强—JMeter、K6、locust、FunTester横向对比。 上次的测试中，我在局域网起了一个基于FunTester moco server框架架构图的服务，服务单机QPS在15k左右到达瓶颈，但是初步判断是局域网带宽导致的，由于时间原因我并没有在深入排查原因。刚好一个朋友想知道Gatling性能测试框架在实际测试中跟其他框架的比较结果，我就趁着周末时间搞了一个本地的moco服务来测试K6、Gatling和FunTe...

在之前写过的文章固定QPS压测模式探索、固定QPS压测初试中，我用到了一个任务发生器和sleep()方法来达到固定QPS的请求实现。但是在最近的工作中，在高QPS场景下，这种方式就会显示出其缺点：单线程任务生成器性能不足，由此带来的副作用就是误差较大。为此，我引入了多线程任务生成器的功能。 主要思路就是在性能测试软启动完成后，根据设置QPS大小分配多个的线程来完成生成任务的功能。 这里引入一个常量： /** * 单个线程执行的最大QPS任务速率 */ public ...

今天填一下之前的坑，前文性能测试误差对比研究（一）中，我对几种比较常见的性能测试误差来源，进行了对比测试。效果还是不错的，基本的结论都是非常清晰的。 今天我继续分享剩下几种性能测试误差来源对性能测试误差影响，以及定量测试其中的影响程度。 测试脚本 由于FunTester已经优化了性能测试框架软启动的问题，总体测试的时间会比较长，所以我这里简单实现了一个简化统计，在测试过程中表现还是很不错的。分享一下Groovy脚本： 这个脚本会在后面测试中略微修改。 package com.funtester...

之前写过一篇固定QPS压测模式探索文章，个人认为这个模型相比固定线程数并发请求压测服务的模型更加贴近实际情况，比较适合做负载测试。在最近的工作中尝试使用固定QPS的压测方案，有了一些实践成果（大部分还是修复了BUG），分享一下。 先说一下实践代码，然后分享一下自己修复的两个BUG。 固定QPS实践 先讲一下最常用的HTTP请求的负载测试实践，跳过单个请求的实践，这里用两个request，通过一个list完成存储，然后创建测试任务。 def requests = [] ...

之前写过一篇如何mock固定QPS的接口，中间用到了流量控制类Semaphore和线程安全的知识。当时在测试过程中，多线程并发请求，QPS误差率在5%以内，觉得算是在可接受范围内的，所以并没有做进一步优化。 最近看了一篇有关*开源*代码文章，有点感触，就在原来的基础上做了优化。主要思路是新建一个线程，通过计算理论值和实际值的差距，通过一个线程安全的对象完成这个补偿修正。 核心代码如下： package com.fun.moco.support import com.fun.frame.SourceC...