有时候会需要在linux的命令行上运行JMeter，简单说一下做法： 在图形界面上创建测试计划，并保存生成的test_plan.jmx文件； 将生成的test_plan.jmx文件上传到linux服务器； 在linux的命令行执行如下指令： 其中-n说明不是在图形界面下执行，-t指示了测试计划文件的位置。 还是写一个简单的示例吧。接下来创建一个HTTP请求的测试计划。 创建测试计划： 添加一个监听器： 这里将监听结果保存到文件。因为没办法直接通过图形界面查看运行结果，需要通过文件查看监听结果。 最后在命令行执行测试计划： 执行结束后可以将执行结果文件拷贝出来，在jmeter中打开查看。

我工作中的笔记本配置还可以。但是在测试一个简单的TCP连接时，发现把线程数设置为10000时，我的笔记本会很快死掉。最终实验出我的笔记本可以承受的安全线程数是5000。可是对应用的最低性能要求就是能承受1w的并发。此时可以采用基于JMeter的分布式测试方案。 如刚才提到的，要求测试应用在1w并发下的表现，而一部计算机所能承受的线程数是5000，那么需要两部计算机。 步骤 具体步骤如下： 为两部机器都安装JMeter； 定义两部机器的角色，一部是master，一部是slave；我们直接操作master，而slave只是负责分担master的压力； 获取slave的ip地址，比如是192.168.1.12； 在master的JMeter目录下打开bin目录，编辑jmeter.properties文件。找到“remote_hosts=127.0.0.1”这一行，将之修改为“remote_hosts=127.0.0.1，192.168.1.112:1099”。其中1099是master和slave的RMI通信端口。编辑完后记得保存； 打开master上的JMeter，点击运行菜单项，运行->远程启动->选择要启动的slave的IP；如果需要全部启动，运行->远程全部启动即可。 注意事项 有几点需要注意： 1. 启动jmeter-server服务时，提示： 这个是开始没有找到ApacheJmeter_core.jar，后来去JMETER_HOME目录下去查找，最后找到了，如果不希望看到Could not find的字样，可以配置一下jmeter_home的路径（即bin目录的上一级目录），这样启动jmeter-server服务时，就只会看到Found ApacheJMeter_core.jar，当远程访问时，会看到控制台上打印出一行：Starting the test on host [ip]:1099 @….（大概是这样的，@后面是执行开始的时间），远程执行结束，会打印一行：Finished the test on host [ip]:1099 @…，表示远程执行结束。 2. 留意一下1099端口，目前暂未确定这个端口是不是可以改的（按理说这个是可以从配置文件中修改的，目前还没有找到如何修改Agent上面的配置，Controller上面的还好修改） 3. Jmeter分布式控制过程中，各个Agent启动的线程数等于线程组中的配置，不是均分线程组中的配置。 参考文档 http://blog.chinaunix.net/uid-26884465-id-3419474.html http://www.51testing.com/html/12/252512-223613.html

JMeter的监听器可以理解为JMeter提供的测试分析工具（或者测试结果报告）。JMeter监听器的监听范围是当前节点及其子节点。JMeter提供了多种测试监听器，这里简单说几个用过的监听器。 创建测试计划 为了演示监视器的作用，我这里做了一个简单的HTTP请求测试。 如何创建测试计划就不多说了，可以参看这篇文章：《使用JMeter》 下图是线程组的配置： 下图是HTTP请求的配置参数： 启动测试，很快就可以生成测试结果报告。 用表格查看结果 下图是表格结果： 还有几个重要的指数： 简单说下表格中的字段： Sample#——每个请求的ID； StartTime——每个请求启动时间； SampleTime——响应每个请求的时间（以毫秒为单位）； Status——请求状态，如果为勾则表示成功，如果为叉表示失败； Bytes——请求的字节数； Latency——延迟时间； ConnectTime——请求连接用时。 几个指数： 样本数目——样本总数（线程数*循环次数），或者说是发送给测试应用的请求总数； 最新样本——服务器响应最后一个请求的时间； 平均——请求响应时间的平均值； 偏离——请求响应时间的标准差。 聚合报告 下图是本次测试的聚合报告： Label——取样器名称； Samples——发给被测试应用的请求总数； Average——请求响应时间的平均值； Median——请求响应时间中值，即50%的请求响应时间都小于该值（一个统计学的概念）； 90%Line——请求响应时间90%线，即90%的请求响应时间都小于该值； Min——最小响应时间； Max——最大响应时间； Error%——出错率（出错的请求数/所有的请求数）； Throughput——吞吐量，每秒/每分钟（具体看“/”后面的单位）处理的请求数； KB/sec——每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec； 【注意】总体值并不是各列对应记录的累加。是以所有Samples为样本的统计值，如：总体Min=min{各个Samples的Min}，总体Max=max{各个Samples的Max}。 Summary Report（总结报告） 下图是本次测试的Summary Report： 觉得这个和聚合报告一起看有点意思。 Label——取样器名称； Samples——发给被测试应用的请求总数； Average——请求响应时间的平均值； Median——请求响应时间中值，即50%的请求响应时间都小于该值（一个统计学的概念）； 90%Line——请求响应时间90%线，即90%的请求响应时间都小于该值； Min：最小响应时间； Max：最大响应时间； Std.Dev——所有请求响应时间的标准差，即是“用表格查看结果”中的偏离； Error%——出错率（出错的请求数/所有的请求数）； Throughput——吞吐量，每秒/每分钟（具体看“/”后面的单位）处理的请求数； KB/sec——每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec； Avg.Bytes——服务端返回给Request数据的平均值（服务端返回所有数据/请求数）。 图形结果 本次测试的图形结果如下图： 这里的几个指数上面都有提到。还是再说一次吧： 样本数目——样本总数（线程数*循环次数），或者说是发送给测试应用的请求总数； 最新样本——服务器响应最后一个请求的时间； 平均——请求响应时间的平均值； 偏离——请求响应时间的标准差； 吞吐量——每秒/每分钟（具体看“/”后面的单位）处理的请求数； 中值——请求响应时间中值，即50%的请求响应时间都小于该值。 查看结果树 下图是查看结果树： 简单说几个概念： 取样器结果——显示的是请求样本相关参数（客户端参数与响应参数） 请求——发送请求的具体值 响应数据——服务端返回的相应参数 ALL！ 参考文章 http://www.51testing.com/html/12/252512-223091.html http://www.cnblogs.com/jackei/archive/2007/01/17/623166.html http://www.cnblogs.com/Carrie_Liang/archive/2008/11/10/1330997.html http://zuoye.baidu.com/question/1d937880d6e95b419397e16b267a71ba.html