性能测试之入门篇
最近在学习性能测试相关的知识，为了更加系统的来学习，特此从最基础的讲起，保证各位广大网友看的明白，后续会不断出记录并产出类似的知识帖子
一、性能测试的基本概念
概念：用一定的工具，找出或者验证某些性能指标值的测试
工具：Jmeter(主流)、loadrunner、wrk、locust、 locust是一个库，简称：locust库
特征：多用户并发，目标不是找bug,是看性能数据
目的：1、找出性能的指标值 （指标值：最大并发用户数\RT\TPS\HPS\资源利用率\……等等）
在项目或者某个接口从来没有做过性能测试时，也就是首次做性能测试，要获取性能指标值作为基准值；当以后再次做性能测试时，可以根据这个基准值来作为判断，性能到底是变好了还是变差了
2、验证性能有没有优化 通过资源的数据来判断性能有没有问题，有没有优化
小提示: TPS(transactions per second):每秒钟处理的事务数
RT(response time): 响应时间
HPS(hit per second)： 每秒钟点击多少下
QPS(queries per second): 每秒查询率
这些性能指标后面内容会细讲
二、广义上的性能测试
2.1 负载测试
负载测试：逐步增加并发用户数，发起请求，找到系统的拐点区间
关键词：逐步加压 与日均访问量有关，前提不知道能承载多少点击量，模拟不断地增加，比如一开始设置50，然后不断地增加用户，看性能指标有没有明显的变化，那么当性能指标值有明显的变化时，那么就大概的可以确定最大并发用户数，
猜并发用户数，怎么来找？
比如20、40、60、每隔20的递增，当在120的时候，性能指标正常，在140的时候，性能出现明显的下降，那么这个拐点区间，就在120-140之间，然后在从120开始，慢慢的递增加1，逐步观察性能指标值的变化，如在134是正常，135是正常出现下滑，那么拐点就是134，基本可以断定这个最大并发用户数量为135
再举个通俗的例子：你不知道你们公司的产品到底能支持多少并发用户，怎么取到那个最大并发用户数量？
比如一开始都会去猜，有的猜50、100；有的猜1000、2000；那么这与公司产品的大概的日均访问量；比如电商淘宝网站，那么日均访问量几千万，那么一开始设置起点，都会比较高
如果是比较小的日均访问量，比如日均访问量才几千或者几万，那么一开始的起点会设置的比较低；日均访问量并不是有多少人访问，千万别搞错了，哪怕一个人点击10次，那就算访问量10，这与多少人没有必要的联系，一般的公司的产品的并发量用户都不是很高，所以在猜的时候，并发用户一开始都是50开始。
2.2压力测试
压力测试：通过一定的并发用户数，持续比较长的时间请求，查看服务器的稳定性
关键词：比较大的压力+比较长的时间*24 考察耐力 —》看你能跑多长时间 不管你多少用户，就看你在服务器上能跑多久
举个通俗的例子，你去跑步，脚上绑个10公斤的沙袋，看你能跑多长时间，跑的越久，说明你的耐力越好，我不管你绑多少公斤的沙袋，我只看你能跑多久；
再举个例子，你公司有个产品，现在要做压力测试，不管是用你们的50个并发用户还是100个并发用户还是200个并发用户，我只管你用了这么多的并发用户，持续向你的服务器一直不间断的发起请求，看服务器运行多长时间不出现崩溃或者什么时候出现异常，看服务器的稳定性；假如出现跑了3个小时，服务器出现崩溃或者重启后才能运行正常，这就说明服务器不够稳定；一般都会跑7*24小时（这是以前，现在一般都是跑几个小时，比如3个小时、5个小时，8个小时类似）；很多公司在做性能测试时，一般会有个提前指标，该应用的生产环境要保证多长时间不出现问题，才算基本合格，至于跑多长时间，由公司自己定
真正的压力测试，不能只跑几分钟或者只跑十几分钟，因为检测的是服务器的稳定性，必须要足够长的时间才能大致检测出服务器稳不稳定
平时在公司做压力测试，可能只跑十分钟就够，但那只是得到一些性能数据的信息
先后顺序：先负载测试，再压力测试：
先做负载测试，找出最大用户数，得到相关性能的指标，找出拐点区间，并缩小到具体的某个值
再做压力测试，你可以用最大并发用户数量去做，当然也并不一定要拿最大并发用户数去做，只要比它小、不超过就行；
其实，负载测试、压力测试，这些都是属于广义上的性能测试
三、性能测试的基本原则和必备条件
3.1 哪些适合做性能测试呢？
因为公司不是所有的项目都需要去做性能测试，所以哪些适合或者说可以来做性能测试呢？
1、交付型产品， 有明确要有性能测试报告的
2、涉及到钱财的、生命安全的 因为出了事责任很大，谁也担当不起
3、大型的新系统
4、某个系统中的核心部分或者核心系统
5、架构调整 比如：jdk1.7变成jdk1.8，一些代码有关的比较大的调整变动
6、业务剧增 比如：双十一，节假日等等
7、重大缺陷修复 比如：该bug的影响范围非常广，甚至是底层的东西
3.2 可测性
可测性：可以量化为性能指标值
比如：举个通俗例子，问大家一个问题：
100w的用户，某一个接口，做个性能测试，做的出来吗？做不出来
首先，活跃用户有多少？这100w用户中一天有多少人来访问？你没有告诉我做这个性能测试，得到的是哪一个指标，是QPS还是RT还是资源利用率，并不知道；也没给我时间要跑多久，所以很多因素确定不了，无法做性能测试，这些确定不了的东西，就要和产品经理或者架构师进行交流沟通进一步确认
假设某个接口的日均访问量大概是500w,需要做个性能测试，怎么来做？
日均访问量，是白天的8小时还是24小时(问清楚，一般都是8小时)；
5000000除以24小时，再除以3600秒，那么每秒大概处理174个请求
这174是什么意思呢？此时可以174个人，每人一秒发一次请求 ；当然了，不一定得174个人来请求，也可以是58个人，每秒内发3次请求也可以；人数 * 每人每秒请求次数 = tps
3.3 基本原则
3.4 必备条件
1、独立的服务器 硬件资源相同、软件配置相同的服务器；如果没有独立的服务器，做性能测试是做不了的
2、独立网络 不能用有线网络 为什么？因为有线网络不够稳定，会造成测出来的性能数据有影响
生产环境不能被用于性能测试；为什么？因在生产环境做性能测试，那产生的脏数据怎么办？如何处理？就算处理，也很麻烦；再一个做性能测试，万一压爆了怎么办?;还有如果做性能测试的过程中影响到了用户的使用怎么办？这才是最重要的，所以不能用生产环境来做性能测试
四、性能测试的主要指标
1、并发/并发数/并发用户数
并发：狭义上讲：同一时间做相同事情 可以向相同的接口发起请求
广义上讲：同一时间做不同事情，混合场景 可以向不同的接口发起请求
并发数：单位时间内向服务器发起请求的用户数 virtual user
并发用户数：用以模拟真实用户向服务器发起请求的性能测试虚拟用户数量
系统用户数：只要访问过系统的用户，包含一次性访问的用户 这里做个解释：只要访问过，后台服务器有历史记录，那么就算是系统用户数
在线用户数：当前正在访问系统的用户 这里做个解释：玩游戏时，哪怕挂机，也算在线用户数，因为并没有退出
2.响应时间：从发起请求到请求响应的时间
网络传输时间 t1 t4
服务器处理时间 t2 t3
3.吞吐量：是衡量 网络 的重要指标
吞吐量是指系统在单位时间内处理请求的数量，TPS、QPS都是吞吐量的常用量化指标
吞吐量 针对的是事务数 事务/s 当网络没有瓶颈时，吞吐量的值 等于tps 的值
吞吐率 针对的是数据量 Kb/s
系统吞吐量要素，一个系统的吞吐量（承压能力）与request（请求）对cpu的消耗，外部接口，IO等等紧密关联。单个request，对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高
重要参数：QPS(TPS),并发数，响应时间
QPS：每秒查询率，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力
TPS: 每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间
关系： QPS(TPS)=并发数/平均响应时间
4.资源利用率
cpu、内存、磁盘、I/O
一般的普通电脑内核都是4G/8G/16G，这里的cpu的利用率是值多核的综合利用率，目前行业内的默认标准一般不超过80%,只要没超过80%,说明还扛得住
所以，以上几项都是常见的性能指标
