性能调优可以从 硬件(计算机体系机构)、操作系统(OS\JVM)、文件系统、网络通信、数据库系统、中间件、应用程序本身等方面入手。
那性能优化有哪些可以参考的指标呢？其实这些指标我们在开篇的时候就已经概述过了，这节课会带着大家一一来解读这些指标。
一、性能优化指标
下面我们详细解读下以下各个性能指标。
执行时间：一段代码从开始运行到运行结束所使用的时间。
CPU时间：(算法)函数或者线程占用CPU的时间。
内存分配：程序在运行时占用的内存空间。
吞吐量：
单位时间内系统处理的客户端请求的数量。
计算单位：一般使用请求数／秒做为吞吐量的单位，也可以使用页面数／秒来表示。另外，从业务角度来说也可以使用 访问人数 /天 或 页面访问量／天 做为单位。
计算方法：Throughput（吞吐量） = number of requests（客户端请求数量） / total time（请求总用时）
吞吐量-负载对应关系：
图中拐点说明：
（1）吞吐量逐渐达到饱和
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位
响应时间：指的是用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应信息结束，这个过程中所耗费的时间就成为响应时间。响应时间越短说明会性能就越好，这个过程通常用 秒 来衡量
响应时间 = N1+A1+N2+A2+N3+A3+N4 （数据库服务器处理时间+应用服务器处理时间+网络传输时间）
网络传输时间：N1 + N2 + N3 + N4
应用服务器处理时间：A1 + A3
数据库服务器处理时间：A2
资源利用率 :
资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU，内存，网络带宽等。资源利用率通常以占用最大值的百分比来衡量。
当某个资源利用率随着负载的增加最终在 100% 居高不下时，就可能意味着这个资源变成了系统的性能瓶颈所在，提高这个资源的量，将会提高系统的吞吐量，同时降低交易的响应时间，即改进了系统的性能。
并发用户数 :
并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
系统用户数：系统注册的总用户数据
三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数
二、其它常用概念
TIPS：Transactions Per Second，每秒事务数
思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的。
点击数：每秒钟用户向WEB服务器提交的HTTP请求数。
这个指标是WEB应用特有的一个指标：WEB应用是”请求-响应”模式,用户发出一次申请,服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求.
PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个 网站规模的重要指标。
UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）
三、性能测试模型
性能测试的概念：通过自动化的测试工具或者手动模拟多种正常、峰值以及异常负载条件来对系统的各种性能指标进行测试。
我们了解了测试的概念，那看下性能测试模型的构建、分析以及在性能优化中如何快速定位性能瓶颈？
模型构建：
在性能测试过程中，建模实际上可分为两个过程，性能测试过程和模型构建过程。
性能测试过程主要完成对系统进行性能测试，并搜集相应的测试结果，形成测试过程文档；
模型构建主要是根据搜集到的性能测试需求和生产系统的相关信息完成性能模型的构建工作，并指导性能测试过程以及测试结果的生成。
模型作用：
对被测试系统抽象出测试模型，并根据性能测试模型分析具体的测试关注点、测试分类、测试影响因子、测试场景，并对实际案例中如何使用应用模型分析测试用例，梳理其分析步骤，在实际案例的性能测试过程中，从性能模型出发，有章可循，对场景和用例分析有很大帮助，可快速定位性能瓶颈。
模型分析：
上图中 X 轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后 进入拐点区后倾斜率增大，响应时间急剧增加。
接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发 用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。
四、小结
在软件交付时，软件性能测试成了衡量这个产品的重要指标，掌握以上各个指标的含义在软件测试环节可以很好的定位问题。
测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的：
测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。
测试人员在做性能测试时除开要关注表面的现象如响应时间，也需要关注本质，比如用户看不到的服务器资料利用率，架构设计是否合理？代码是否合理等方方面面
开发者性能调优也需要掌握基本的测试技能、分析技能、测试软件应用技能…
很多小伙伴看到这觉得要掌握的技能太多了从而“望而却步”，不用担心，下节我们介绍下性能分析的小技巧，帮助我们快速的定位问题。
是否合理？代码是否合理等方方面面
开发者性能调优也需要掌握基本的测试技能、分析技能、测试软件应用技能…
很多小伙伴看到这觉得要掌握的技能太多了从而“望而却步”，不用担心，下节我们介绍下性能分析的小技巧，帮助我们快速的定位问题
