接上一篇，当我们把准备工作都做好后，就可以加负载了！
一般的公司都想知道自己产品的性能瓶颈和以及提升性能，以期大流量来了还撑得住。
其实性能测试很难，难点在你不知道性能要达到怎样的需求。
难点在于你没有实际的环境场景给你测试，总不能给线上环境你测试吧？
难点在于找性能瓶颈，即便找出来了，调优也是一件棘手的事情。
一般公司的性能测试都是在测试环境下模拟和估算。(当然大公司不是这么干。淘宝双11，12306节假日的超大流量这么干绝对死翘翘)
如果一个团队能走如下流程
那么测试人员就轻松多了，它只需要设计场景以及执行，并能找出瓶颈。
如下图，我们设计的并发数，进程数乘以循环次数，相当于设计了100个用户在同时登录
测试结束后，生成本次测试的报告。
生成报告又分为非GUI和GUI报告。
JMeter3.0版本发布后，开始支持动态报表报告。让测试人员编写性能测试报告更加容易。
jmeter -n -t test.jmx -l result.jtl -e -o /tmp/ResultReport
结果如下：
参数说明:
-n: 非GUI模式执行JMeter
-t: 执行测试文件所在的位置
-l: 指定生成测试结果的保存文件，jtl文件格式
-e: 测试结束后，生成测试报告
-o: 指定测试报告的存放位置
-l -o指定的文件及文件夹，必须不存在，否则执行会失败
将已存在的测试结果文件，生成测试报告
jmeter -g result.jtl -o /tmp/ResultReport
参数说明:
-g: 指定已存在的测试结果文件
两种方式，其实最终都依赖生成的测试报告。双击报告文件夹中的index.html即可查看报告。
GUI报告就是聚合报告，可以导出来
然后计算
从报告中计算出
如100个用户2s内登录 总的执行的时间=最后一个线程启动的时间+最后一个线程持续的时间-第一个线程启动的时间
throughput=总的线程数/持续时间=100/4.524=22.1个线程/sec
需要了解的一些概念
1、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
2、Transactions per Second（每秒通过事务数/TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
3、Hits per Second（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
4、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
测试指标
对于B/S架构的软件，一般会关注如下Web服务器性能指标：
Avg Rps：平均每秒钟的响应次数=总请求次数/秒数；
Avg time to last byte per terstion （mstes）:平均每秒业务脚本的迭代次数；
Successful Hits：成功的点击次数；
Hits Per Second：每秒点击次数；
Attempted Connections：尝试连接数；
Throughput：吞吐率；
对于C/S架构的程序，由于软件后台通常为数据库，所以我们更注重数据库的测试指标。
User Connections：用户连接数，也就是数据库的连接数量；
Nunber of Deadlocks：数据库死锁；
Butter Cache Hit：数据库Cache的命中情况。
注意：
在实际性能测试过程中，需要观察的性能指标并不限于以上提到的这些指标，需要根据实际情况作出选择和权衡，有些指标如CPU占用率、内存占用率、数据库连接池等，也有非常重要的参考意义。
