为什么会有性能问题？ 其实任何程序都需要资源 cpu 内存 磁盘 网络。那资源是无限的吗 很显然不是的。

我们举个例子 我们打开一张页面查看一张图片

我们的浏览器需要请求服务器 （在这之间就需要占用网络资源）

服务器中会有很多的功能 比方说某一个程序 服务器要访问就要代码指令（会占用cpu）

 那我们图片放在磁盘/硬盘中 （磁盘资源，持久存储）

那我们请求图片 图片怎么到网卡的呢？是由cpu读取数据 然后转到网卡

那如果cpu读取的话就太慢了 所以在cpu和磁盘中间还有内存  

正常情况下 图片会从磁盘中读取，然后放到内存里面，内存在通过cpu（cpu是调度执行 cpu不会完全存储图片 而是会有一小部分空间 一边读一边传输） 传给网卡 网卡在通过网络请求 返回给浏览器 。

所以我们看到图片 后台是会占用很多系统资源的 当系统资源不够用的时候性能问题就出现了。

比如我们的图片大小是1M（1兆 ），而我们的网络兴许就是10M或者20兆这样的， 现在有一个人在访问我们的系统 我们照片也经过网络在传递 。如果这时候有第二个人来访问我们的系统，他不一定会马上看到我们的图片，因为网络太拥挤了。所以性能问题就来了。

那我们性能问题 会有很多的性能指标，从用户角度出发。这个很重要！！！

如果说用户角度：首先是能不能用 用起来快不快

快不快是什么--响应时间（一次操作的完成时间）我们打开这个网站从打开到页面完全出来这个整体的时间

响应时间：网络等待的时间和处理的时间---页面响应时间（页面多个子资源累加计算）

接口响应：单接口请求--接受响应的完整时长

我们打开网页这些资源统统都算在响应时间内 这些都看作是api 只是有些接口返回css 有些返回js等等 

能不能用是什么--功能层面我们不赘述，人多的时候能不能用，比如公司有一万名员工 同时在早上9点上班打卡 那这个打卡系统能不能用呢？ ---这就是并发量

而并发量又分 绝对并发和相对并发

相对并发：指某个时间段内向服务器发出请求的并发（秒/单位）比如双11 每秒几十万请求

绝对并发：同一个时间点 服务器接收到的请求量

我们说了用户角度 还有成本角度

做性能测试是多方面的 我们从用户角度出发 也要考量公司关心的指标 ，比如说资源占用率 。

那什么是资源占用率？--我们在程序运行中对服务器资源的占用

比方说 同样的产品A公司每年服务器花费10w 得到的收益是30w 而我们的产品 每年服务器花费20w 得到的收益是30w 别人1m带宽 内存2g 而我们需要2m带宽 内存4g  。一个用户请求需要占用多少资源 这就是资源占用率 别人1m带宽，而我们需要2m带宽 这就是程序的性能另一种体现。

比如以下图片 我们页面加载这张照片需要55.7kb，同样的照片我们如果能压缩图片到27.8kb，我们这种情况下打开网页的资源占用 对网络带宽的资源占用 对磁盘和内存的资源占用是不是少了一半。

吞吐量：输入-处理-返回 吞吐就是每秒能够完成多少次请求（反应系统的处理能力的综合体现）吞吐量肯定是越大越好，但并不代表响应时间就快。

吞吐量和并发量的关系/区别

打个比方：酒店里有两个前台 前台接待客户 处理5分钟/人，我们这种场景 吞吐量就是5分钟两笔，2个请求/5分钟==2/5min

那如果我们一下来了10个人，（酒店相当于我们的系统 ）来10个人酒店肯定能处理，2个人处理 8个人等待 过了3分钟又来了10个人，那这个时候我们吞吐量是没有变化的还是2/5min，后来的10个人的空间可以站着继续等待，那又过了5分钟又来了10个人 那这个时候酒店已经慢慢装不下了，但是我们的前台接待也是人啊 人多氧气就不够了，后面人也进不来酒店了。

也就相当于我们的系统在不断的有人请求 而我们的吞吐量处理的能力如果小于并发量，在一定时间之内肯定会出现问题。反之如果吞吐量大于并发量 系统能够轻松的处理 

应用角度：QPS、TPS

QPS-对请求的处理：每秒查询率（每秒查询率 针对查询、请求处理、每秒能处理多少）select，不涉及数据变更操作。

TPS-对请求的处理：每秒处理的事务数，涉及数据变更操作

网络角度--字节/秒：服务器每秒能够接收多少数据量 服务器每秒能够返回多少数据量 。一般是看服务器带宽 一般做性能瓶颈分析的时候会用到