Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值
#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间。单位ms
Median：中位数，也就是 50％ 用户的响应时间
90% Line：90％ 用户的响应时间
Min：最小响应时间
Max：最大响应时间
Error%：本次测试中出现错误的请求的数量/请求的总数
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数
KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec
结论：
1. 90％用户响应时间在 Jmeter中是可以设置的，你可以改为80％或95％；
设置方法：找到bin目录下的jmeter.properties文件，修改aggregate_rpt_pct3=99.99，重启jmeter。
2. 对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况；
3.从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；
4. 你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；
5. 果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；
6. 在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；