一、服务器性能

平常的工作中，在衡量服务器的性能时，经常会涉及到几个指标，load、cpu、mem、qps、rt，其中load、cpu、mem来衡量机器性能，qps、rt来衡量应用性能。

一般情况下对于机器性能，load、cpu、mem是越低越好，如果有一个超过了既定指标都代表着可能出现了问题，就需要尽快解决（当然有可能是应用的问题也有可能是机器上其他程序引起的），反正就是如果不解决，时间长了肯定不好。

而对于应用性能的两个指标，qps当然是希望越大越好，rt越小越好。提高qps可以充分利用机器资源，更少的机器来完成更多的请求，而降低rt会提升响应速度，提升用户体验。

平时做性能优化或者查找性能问题的目的，就是在提高qps，降低rt、保证load、cpu、mem稳定，但是至于他们之间有什么关系，是否有相互影响，各个指标主要由那些因素决定等等，往往是两眼一抹黑。优化点做了就是做了，至于会有什么结果，为什么会生效，会不会对其他指标有什么影响，心里多少是没有底的，先上线看看再说，不行再来。

本文的目的是梳理下日常工作中涉及到性能点时的一些思考，总结方法和理论，形成自己的方法论，希望对以后类似的工作有一定的指导。

文章的内容主要来自《服务器端性能优化-提升QPS、RT》、《由RT、QPS到问题排查思路》两篇PPT和ata上的一些文案的总结，涉及到具体测试案例可以参考着两篇ppt中的例子。

在文章开始前，大家可以思考几个具体的问题：

如果要提高qps应该怎么做，如果要降低rt应该怎么做？

qps和rt的关系，降低rt就可以提高qps？qps低是因为rt高导致的？

应用中线程的数量怎么设置，是越多越好，线程在应用性能中的作用是什么？

系统负载和应用负荷的关系，系统负载高是由应用负荷引起的，如果不是还有什么原因？

二、应用性能

1、理论讨论

在进行理论总结之前，对接下来要用到的一些参数做下说明：

qps：一秒钟内完成的请求数量

rt： 一个请求完成的时间

Tic： 线程的cpu计算时间

Tiw：线程的等待时间（io/网络/锁）

Tn： 线程数

Tno：最佳线程数

Cn：cpu核数

Cu：cpu使用率

三、机器性能

接下来让我们来看看衡量机器性能的指标——load 和 cpu使用率。

cpu使用率：程序在运行期间实时使用的cpu比率。

load：代表着一段时间内正在使用和等待使用cpu的任务平均数，这是一个很玄妙的定义，我至今没有完全明白它的确切的定义和计算公式。

鉴于load的计算没有明确的计算公式，因此不好分析影响load的因素，也不好像应用性能那样总结出影响qps和rt的具体原因，现在只对load表现出来的问题做一些总结。

机器负荷高，但应用负荷不高

即机器的load很高，但是应用的qps、rt都不高，这种情况可能有以下几种原因：

• 其他资源导致cpu利用率上不去，大量线程在执行其他动作或者在等待，比如io的速度太慢，内存gc等。
• 如果系统资源不是瓶颈，则由可能是锁竞争、后端依赖的服务吞吐低、没有充分利用多核资源，多核却使用单线程。

查看机器load高的常见方法：

• 机器的io（磁盘io、网络io）：vmstat、iostat、sar -b等。
• 网络io：iftop、iptraf、ntop、tcpdump等。
• 内存：gc、swap、sar -r。
• 锁竞争、上下文切换、后端依赖。

机器负荷高，应用负荷也高

即机器load很高，应用qps也很高：

• 典型的cpu型应用，rt中Tiw很小，基本上全是cpu计算，可以尝试查找cpu耗的较多的线程，降低cpu计算的复杂度。
• 应用的负荷真的很大，当所有优化手段都做了，还是无法降下来，可以考虑加机器，不丢人。

对于load偏高的原因，不仅仅只是有应用自身引起的，机器上其他程序也有可能导致机器整体的load偏高。

四、总结

影响系统性能的具体因素还有很多，如内存就是很常见的问题，内存泄露、频繁gc等，因此内存也应该被重视，限于篇幅，内存的问题不专门展开。

影响系统性能的因素有很多，没有一个明确的公式或者方法能说明是哪一个具体的因素对系统造成了多大的影响，对其他相关因素又产生了多大的影响，影响是好是坏。

正是因为这种复杂性和不确定性给系统性能优化和查找性能问题带来了困难，实际工作中还是要针对具体问题具体对待，但是我们可以对已知的问题和方法做归纳和总结，并逐步在实际问题中去验证和丰富扩充，以形成解决问题的方法论。

[2019-08-22 16:34:55]