基础概念的交流有助于意识层面的沟通和理解保持一致。 **资源(resource)**：物理服务器的功能组件，一些软件资源也可以被衡量，比如线程池、进程数等。系统的运行，需要各种资源，对于资源列表的确定，我们可以凭借对系统的了解确定，也可以通过绘制系统的功能块图的方式确定要衡量的资源。 常见的物理资源如下， CPU（cpu sockets）、CPU核（cores）、硬件线程（虚拟线程）hardware threads( virtual threads)、内存、网络接口、存储设备、存储或者网络的控制器、内部高速互联 **负载(load)**：有多少任务正在施加给系统，也就是系统的输入，要被处理的请求。对于数据库，那么负荷就包括了客户端段发送过来的命令和查询。 负载如果超过了设计能力，往往导致性能问题。应用程序可能因为软件应用的配置或者系统架构导致性能降低，比如，如果一个应用程序是单线程的，无疑它会受制于单线程架构，因为只能利用一个核，后续的请求都必须排队，不能利用其他核，但也可能仅仅是因为负载太多了。负载太多将导致排队、高延时，比如，一个多线程应用程序，你发现所有cpu都是忙的，都在处理任务，这个时候，仍然发生排队，系统负载很高，这个时候很可能是施加了过高的负荷。 如果在云中，你也许可以简单地增加更多的节点来处理过高的负荷，在一般的生产应用中，简单增加节点有时解决不了问题，你需要进行调优和架构迭代。 **利用率(ulilization)**：利用率用来衡量提供服务的资源的忙碌程度，它基于某一段时间间隔内，系统资源用于真正执行工作的时间百分比。即， > 利用率 = 忙的时间 / 总计时间 利用率可以是基于时间的，比如cpu的利用率：某颗cpu的利用率或者整体系统的cpu利用率。比如磁盘的利用率，我们可使用iostat命令检查%util。 利用率也可以是基于容量的，它可以表示我们的磁盘或者内存或者网络的使用程度，比如90%的磁盘空间被使用，80%的内存被使用，80%的网络带宽被使用。 可以用高速公路的收费站的例子来类比： 利用率表现为当前有多少收费亭正在忙于服务。利用率100%，就表示所有收费亭都正在处理收费，找不到空闲的收费亭，就必须排队。在高峰时刻，可能许多时候收费亭都是100%的利用率，但如果给出全天的利用率数据，也许只有40%，如果只关注全天的利用率数据就会掩盖了高峰时段的利用率的一些问题。 往往利用率的高位意味着资源饱和。利用率100%往往意味着有瓶颈，检查饱和度、系统性能可以确定。该资源不能提供服务的程度被标识为它的饱和度，见下面饱和的详细解释。 利用率超过60%也可能有问题，如果是检测的结果百分比数值比较大，很可能掩盖了偶尔的100%的峰值，意味着一些资源，如磁盘，在60%的利用率的时候，就开始性能变差了。 **响应时间(response time)**：也叫延迟，指操作执行需要的耗时。它包括了等待时间和执行时间。对于一个数据库查询，那么响应时间包括了从客户端发布查询命令到数据库处理查询，传输结果给客户端的所有时间。延迟可以在不同的环节衡量，比如访问站点的装载时间包括DNS延迟、tcp连接延迟、tcp数据传输时间。延迟也可以在更高的级别理解，包括数据传输时间和其他时间，比如从用户点击链接到网页内容传输，并在用户的电脑屏幕上渲染完毕，这也是一种延迟。延迟是以时间做量度来衡量的，可以很方便地进行比较，其他的一些指标不容易衡量、比较，比如IOPS，那么，你可以转化为延迟来进行比较。 **伸缩性(scalability)**：可以理解为两个层面的意思。 一、在资源的利用率不断增加的情况下，响应时间和资源利用率之间的关系，资源利用率越高，响应时间仍然能保持稳定，那么我们说他的伸缩性好，但如果资源利用率高，响应时间开始劣化，我们认为其伸缩性不佳。 二、伸缩性还有一层意义，表征系统不断扩展的能力，系统通过不断增加节点或者资源，处理不断增长的负荷，同时依然能够保持合理的响应时间。 **吞吐(throughput)**：处理任务的速率。对于网络传输，吞吐一般指每秒传输的字节数，对于数据库来说，指的是每秒查询数（QPS）或者每秒事务数。 **并发(concurrency)**：指得是系统能够并行执行多个操作的能力。如果数据库能够充分利用CPU的多核能力，那么往往意味着更高的并发处理能力。 **容量(capacity)**：容量指的是系统可以提供的处理负荷的能力。我们日常运维中有一项很重要的工作就是容量规划，即确保随着负荷增长，我们的系统仍然能够处理负荷，也就是说，当我们的吞吐增加后，我们仍然能够确保服务良好、稳定。容量也指我们的资源使用极限，比如我们的磁盘空间占用，在磁盘空间到达一定阀值后，我们可能要考虑扩容。 熟悉以上概念，并且了解他们之间的关系，一般来说，随着负荷上升，吞吐率将上升，吞吐曲线会一直是线性的，我们的系统的响应时间开始一个阶段会保持稳定，但是到达某个点后，性能开始变差，响应时间变得更长，以后随着负荷继续增加，此时我们的吞吐将不能再继续增长，甚至下降，而响应时间可能变得不可接受。 有一种例外情况是，应用服务器返回错误状态码，比如web服务器返回503错误，由于基本不消耗资源，难以到达极限，所以返回错误码的的吞吐曲线还会继续保持线性。