基础概念的交流和理解一致，才有助于意识的沟通一致。才有助于意识层面的交流。
资源(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错误，由于基本不消耗资源，难以到达极限，所以返回错误码的的吞吐曲线会保持线性。