jmeter怎么判断已到并发数

通常会设计一个阶梯场景，使用阶梯线程组，每隔一段时间，自动增加固定量的并发用户数。
然后，通过监听器或监控平台查看运行结果，分析运行结果判断是否达到了性能瓶颈，从而断定是否达到了最大并发用户数区。
然后，再取这个最大并发用户数区间，缩小固定递增步长，从而获得最大并发用户数。
无论是从成本角度还是维护的难易方面，压测机的数量，适量就好。举个例子，8C16G的一台服务器，部署jmeter后，根据我个人的测试比对数据，配置≤1500个线程数，最好。太多了性能损耗较大，延时高；太少了又浪费。
2、controller&agent
模拟的并发线程数超过5K，我个人建议留出一台做专门的controller机器，主要是避免agent机器数据上报带来的影响(如果有其他的数据存储+可视化服务，可以忽略)。

状态时许图：

抓包图：

状态时许图：

抓包图：

参数：

Name ：名称

Comments ：评论

TCPClient classname为TCP Sample使⽤的TCP Client的实现，可以是⾃定义的，可以是JMeter提供的。

TCPClientImpl ：TCPClient最简单实现类，也是默认使⽤的Client。以⽂本⽅式发送和接收数据。读取响应时读到输⼊流结束或者结束符停⽌。其中结束符通过JMeter属性的tcpeolByte定义。使⽤的字符集通过tcpcharset配置。

BinaryTCPClientImpl ：TCPClient的⼆进制实现类。以⼆进制（Hex流）的⽅式将配置的数据传送， 所以要求配置的数据必须是⼆进制（Hex流）。读取数据的时候会把数据重新转为⼆进制（Hex 流）。读取响应时⼀直读到输⼊流结束，或者定义好的结束字节，该字节通过 tcp BinaryTCPClienteomByte配置。

LengthPrefixedBinaryTCPClientImpl ：BinaryTCPClientImpl的扩展类，在⼆进制（Hex流）的前⾯增 加了默认2字节的⻓度。也就是说对于配置的数据，该类会⾃动增加2字节的⻓度数据。2字节的配置可以改变，通过tcpbinaryLengthprefixlength配置。

Server Name or Ip ：服务名称或者IP

Port number ：端口号

Timeouts-Connect（milliseconds） ：连接超时时长

Timeouts-Response(milliseconds) ：响应超时时长

Re-use connection :选中表示重⽤TCP连接，含义是同⼀线程重⽤，即同⼀个线程内的多个请求使⽤客户端同⼀IP和相同端⼝与服务器连接，服务器维护的是⼀个TCP连接。当然，并发的不同线程使⽤的不同的连接。当在请求过程中出现错误，即使该配置被选中，也会在下⼀次请求时重新打开⼀个连接。哪些配置会影响请求的错误判断呢？配置⽂件中的tcpstatusprefix、tcpstatussuffix、 tcpstatusproperties还有就是tcphandler。后者是配置的TCPClient实现类，响应结果直接决定请求的成败。前两者是是如何获取服务端状态码，tcpstatusproperties是如何翻译获取的状态码。这些状态码可以决定请求的成败。注意，⽬前JMeter⽆法配置哪些成功、哪些失败，默认的 "400"-"499" and "500"-"599" 就是失败。

Close connection ：选中表示请求结束后关闭连接。该配置会影响Re-use connection，如果选中Close connection则⽆论Re-use connection是否选中，都会在请求结束后关闭连接，⽽下⼀次请求重新创建⼀个连接。也就是Re-use connection配置⽆效。

Set NoDelay :选中则禁⽤ Nagle算法，与TCP协议的缓存有关的算法。简单讲就是，是⽴即发送数据，还是缓存⼀会⼉收集⼀个⼤包再发送。有实时性要求的系统设置NoDelay，默认是关闭的（就是默认的TCP协议启⽤Nagle算法）。

SO_LINGER ：TCP协议中的延迟关闭时间，具体参考TCP协议。简单讲就是客户端要关闭连接时，是否要等待以秒为单位的时间。默认不配置或者配置为0，可以防⽌服务端维持⼤量处于TIME_WAIT状态的连接。

End of line(EOL) byte value : 结束字符配置，可配置的值在-128到+127。 与配置⽂件中的tcpeolByte⼀个作⽤。

Text to send :发送文本

Login Configuration ：

Username ：用户名称

Password ：密码

TCP短连接 ：发送1次请求，关闭连接。

TCP长连接 ：发送N次请求，再关闭连接。

连接数满

设置了keep alive 导致的网络连接超时

网络延迟

丢包

参考:
>不够。
jmeter的架构和loadrunner原理一样，都是通过中间代理，监控和收集并发客户端发出的指令，把他们生成脚本，再发送到应用服务器，再监控服务器反馈结果的一个过程。

Apache Bench（简称为ab）是 Apache 提供用于对Apache >右上角设置->高级->系统->打开您计算机的代理设置->连接->局域网设置->勾选“为LAN使用代理服务器”->地址输入：127001->端口输入：8888->勾选‘’对于本地地址不使用代理服务器->确定。

PS：设置代理时要关掉抓包工具，因为它也是一个代理服务器。

注：jmeter自带代理服务器

1、设置代理

启动Jmeter->测试计划->右键添加“非测试元件”->选择>最近在给产品线做基于dubbo协议的java服务测试，我本机没有配置dubbo服务容器，先让同事提供测试类，我再对测试类工程导入jmeter的jar包，封装成jmeter可执行的jar包。基于本次性能测试的要求，要把脚本放在linux下部署好了 dubbo服务的机器上测试，多次尝试后选择了用jmeter远程分布式调用的方式。
jmeter远程分布式调用，可以使用本机做控制端，其他已经搭建好dubbo协议的电脑或者linux服务器做测试服务端

配置要求是两台windows机（ip：13433170：1888，1342220:1899）和linux服务器（ip：13017129:2099）都使用相同版本的jmeter，本次测试使用的是apache-jmeter-31

首先配置window控制端修改jmeterproperties,在remote_hosts=添加远程服务端地址和端口

其次配置windows服务端 修改jmeterproperties，取消server_port=1899和serverrmilocalport=1899前面的注释，设置远程端口为1899，默认为1099，建议修改一个其他数值。

启动jmeter_server会显示一个

这里的ip地址就是和控制端配置的remote_hosts一致。

报错问题记录：

1、配置完成后测试提示connnection refused 原因是：服务端的防火墙为关闭，禁止访问，关闭防火墙就可以ping通

2、可以访问后再测试提示：

原因就是如果服务端的jmeterproperties中的server_port和serverrmilocalport端口未指定，打开jmeter_server后端口是变化的无法捕捉。

接下来配置linux服务器的jmeterproperties的server_port=2099和serverrmilocalport=2099。在/apache-jmeter-31/bin下执行/jmeter_server提示endpoint为127001:2099，控制端调用的时候提示

查找原因如下：服务器配置了双网卡，内外网的隔离，jmeter在启动时会优先找内网地址，不识别配置的服务器地址，修改方法如下：修改/ossapp/apache-jmeter-31/bin下的jmeter_server文件修改RMI_HOST_DEF=-Djavarmiserverhostname=130178129保存。在windows控制端重新测试，完美执行，监控linux下日志

---