麻烦问一下还在招吗？加班情况怎么样

是的。方便区分场景。一个线程组就是一个场景。传线程数量进去就会启动， 默认 0Jmeter 自动不执行当前线程组

没有性能测试平台支持的情况下， 用 jenkins 驱动 jmeter 也还可以吧。起码比每次都服务器上执行那么长的命令方便很多

https://testerhome.com/topics/23444看看这个··

https://testerhome.com/topics/23444
看看这个。

问一下，使用自定义函数的时候，需要传递给函数的参数带"+","-"这些特殊字符的时候直接整个 ${fun()}就都变成字符串处理，这些特殊的字符如何当做字符串参数传递？

https://testerhome.com/topics/23444，看看我这个呢，也比较简单的

报告还用过 influxdb+grafana 的方式，可惜业界比较认 Jmeter 原生的报告。grafana 展示的不太认可。加上碰到了一些日志存储之类的问题。放弃。。
看到其他人用 es+FileBeats+Kibana 收集日志的方式。有机会自己也要试下

官方提供了杀掉 slave 进程和停止测试的 2 种脚本。直接触发一下多方便。。

jmeter bin 目录下 自带了停止 jmeter slave 的脚本。。。。。不需要自己去找进程 kill 掉

大型分布式下，无法长时间运行的。会内存溢出。导致集群崩掉。我之前就是用这种方法

鼠标选中文件右键重新命名就好了

报错太不友好了。413。猛的以为平台炸了。。

jmeter.property
mode=standy

其实例如阿里的 PTS，腾讯的压测大师，美团的什么锤。大型的互联网公司都会有一些自己的封装一些压测平台的，最近在找比较方便的压测平台，感觉开源的就楼主的最好了。。
希望楼主可以持续更新。或者改成收费也行。

Jenkins 挺方便的，同时利用 shell 脚本写了一些启动停止和重启 jmeter-sever 的脚本，利用 Jenkins 触发。

还有手工把文件分割成指定份数，并用脚本传不同文件到不同服务器并把名字改成一致，或者把相同的参数化的文件发送到 slave 机器上

感觉这些都可以在平台上面实现呢。如果可以做到，对我们这样的平民测试简直如有神助啊。

所以我就是每个场景放一个线程组，不然没办法控制线程比例，但是我认为这样已经可以了，在深就是 jmeter 的底层原理了，不太明白什么时候需要控制每个线程组的线程数量比例，原生只能控制线程组的数量，但是这样已经够了吧。针对每个场景不同的每个接口线程比例可能不同的话， 原生有很多控制器可以做到对单个线程组内线程进行比例控制吧，如果提升一级到控制不同线程组来达到不同场景的需求。原生应该做不到。原来的设计思想可能是每个线程组可满足一个场景即可，测试人员只需要控制线程组的线程数量，用控制器来分配线程即可。
楼主说的 “平台需要根据比例计算出数量，传给 Jmeter 让其执行” 我理解平台可以做到算出线程组的线程数量就 OK 了，简单看一下 jmeter 的启动日志会发现线程是根据线程组来启动的，线程的分配应该是按照脚本的执行顺序或者控制器来实施。平台介入的话应该会对原生的逻辑进行改动。

说的可能有点乱。但是总体意思就是平台只需做到可以控制线程组的线程启动数量即可。甚至平台用 总线程数/单个 slave 最大启动线程数量，结果舍去小数点并 +1，然后用总线程数/前面的结果即可。这样也不用更改 jmeter 原生的线程控制。
举个例子：
单个 slave 最高启动 1000 线程，需求 7500 并发
平台:7500/1000=7.5 舍去小数点并 +1=8,7500/8=938（四舍五入得整数）得出每个 slave 需启动 938 个线程即可，所有的 slave 线程数一致。无需更改原生的逻辑

我这边因为资源有限，所以简单做了一个 jmeter 和 Jenkins 的集成，主要依靠 shell 脚本。
在 Jenkins 构建的时候设置脚本启动的线程数量，并通过变量传到构建的 shell 脚本里，shell 脚本是启动 jmeter 的命令通过全局变量把脚本运行时间和线程数量传输到脚本里面。把生成的日志&&html 报告等等指定在工程在 Jenkins 里对应的工作空间中，

可直接查看

明白，因为最近的项目客户请了 TestIn 的同行来做压测，看到他们封装的 Jmeter 平台支持在平台设置脚本线程数量，以及运行时间，保存请求失败结果等等，联想到之前多个压测机器用不到的时候会有资源浪费，他们的平台就会自动分配每个 slave 机器的线程数，至于 “直到达到指定线程数量” 楼主可能没理解，这个意思是假如每个压力机平台可设置最高启动 1000 线程，当我在平台设置总线程数量为 7500 的时候平台就可以算出需要 8 台压力机，具体是使用 8 台压力机平分 7500 这个数字（原生），还是控制 7 台压力机执行 7000，一台执行 500，平台可以在做研究那种方法比较好。同时楼主提到的多个线程组的控制，这个我没到没想到，因为 jmeter 整体是一个进程，每个线程组线程数的比例，jmeter 原生本身会做控制，这个并不需要平台介入吧。不过确实 TestIn 同事的脚本所有的场景都放在了一个线程组下面，用控制器来隔离，很大很大。不知道是不是他们的平台也碰到了楼主说的线程组线程分配的问题。

另外想问一下楼主更新成分布式的时候支持不同 slave 可以执行不同的线程数，可以设定一个单台 slave 最高启动线程数量，当总线程数大于单台的时候，就自动拉起另一个试压机，直到达到指定线程数量，压测调试的时候不是每次都要开启所有的压测机器，但是不同的系统又占用相同的压测资源。前一段时间我这边有 1 台 16c32g+20 台 4c8g 压测机。我的办法是通过 Jenkins 执行，构建器为 1 新的压测任务让他自动排队，但是这样也会有资源浪费

@suda23 同步 master 到 slave 上面会对文件自动分割么，假如参数化的文件是一次性文件，每个 slave 上面的同一个文件内容肯定是不同的。不然会报错。

感觉楼主对 jmeter 研究挺深的，希望以后有兴趣可以出一个单机 Jmeter 调优，和分布式 master&&slave 调优，比如内存堆栈大小，GC 值等

关于 jmeter 也不是太懂。但是最多的时候一个 master 不做压力机，后面有 15 个左右的 slave，但是我来做一般每个 slave 最多 500 线程，然后看到网上有说每个 slave 不要超过 200 个线程，100 个最佳，所以也不太清楚到底多少合适，之前用的 8c16g 开 3 个进程 每个进程 300 线程左右，观察 slave 机器 CPU 只有在启动的时候会暴增，之后会平稳，内存使用也基本在 12g 以内。但是关于楼主说的负载机是搞 CPU 消耗的应用，这个在我这边用的有点奇怪，有时候做压测 CPU 使用会比较高，有的时间就比较低，不知道是为什么，
同时问一个问题，楼主的压测平台是避免了 负载机过多导致控制机性能不够用的场景么，但是看楼主分布式节点启动的还是 jmeter-server 问一下 master 机器是平台的系统配置的本地绝对路径的 Jmeter_HOME 么

哈哈 非常感谢，因为我司重要项目压测的时候 一般申请 8-10 台（因为不太懂所以只能多加压测机器。。）8c16g， 这样的机器运行一个 slave 太浪费了。所以单个 ip 不同端口 部署多个 slave 机器 在试用的时候发现 StressTestSlaveService 添加的时候 ip 不能重复，仔细查看发现 test_stress_slave 表设置了 IP 为索引。于是把索引删了。。。保存成功 但是因为今天下午刚本地部署成功，还没来得及看代码（虽然也看不懂。。）不知道删掉这个索引 会不会触发其他问题

把。TPS 和 Responsetime ，查看结果树 删掉后 确实成功了。。