双11备战前夕，总绕不过性能压测环节，TPS 一直上不去 / 不达标，除了代码上的问题外，服务器环境、配置、网络、磁盘、CPU 亦是导致性能瓶颈的重要一环，本文旨在分享最近项目性能压测过程中的排查经验，文中的表单你可以作为排查手册保存，如有不对之处，还请在评论区分享、交流你的经验和观点：）

通过本文，你可以了解和掌握：

• 了解常见的系统瓶颈的可能原因。
• 通过性能探查器定位性能瓶颈。
• 几点关于性能优化的策略。
• 一份关于 windows 性能监视器的部分计数器翻译及对应的经验结论。

吞吐量 和 延时的关系

关于吞吐量/吞吐率、延时，你可以通过 Jmeter中的”聚合报告“和”用表格查看报告“来获取。

• Throughput 越大，Latency 越差：因为请求过多，系统繁忙导致响应速度降低。
• Latency 的值越小说明能支持的 Throughput 越高：Latency 数值小说明系统处理速度快，自然便可以处理更多的请求。
• Throughput "不用" 通过降低 latency 的方式来提高，排查性能问题的时候，勿在降低 Latency 值上消耗过多时间。

常见系统瓶颈：

• 类型转换：除了装箱拆箱外，还要着重看下 JSON 的一些转换类库，如 newtown，fastJson 等等，可能会引起 CPU 维持在高位。
• 异步操作：有些异步操作会非常影响性能，尤其是在网络较差的情况下，很可能阻塞业务。
  • 如异步下的状态通知通常会影响性能。通常而言，异步操作会让”吞吐率“提升，但会牺牲 延时（latency）。

定位性能瓶颈

定位的方式不一定是程序级别的，一开始可以先从操作系统的 CPU 使用率，内存使用率，系统 IO 和 网络 IO，网络连接数 着手分析。

• CPU 使用率不高，但是 throughtput 和 latency 上不去： 说明程序没有忙于计算，可能问题在 I/O 上。
  • 一般 CPU 和 IO 是反着来的： CPU 没问题，问题可能在 IO，反之亦然。
• 如果 CPU、IO、内存、网络带宽使用都不高，但是系统性能上不去： 说明程序有问题，可能是为资源被锁，存在锁竞争关系，程序被阻塞；或者是在上下文切换等等。
• 关于 IO，要看 3 个方面：磁盘IO，网络IO 以及 内存换页率。
• 程序级别的性能瓶颈定位：
  • 分段注释代码 / 让一些函数空转 / 做一些硬编码的 Mock，然后再测试下 Throughput 和 latency，看是否有好转，如果有，说明函数是瓶颈，再进一步在这个函数体内注释代码，直到找到最耗性能的语句。
• 分析内存：需要用到的计数器：Memory 类别 和 Physical Disk 类别的计数器，步骤如下：
  1. 查看 Memory：Available Mbytes 指标：如果该指标的数据较小，系统可能出现了内存方面的问题，需要继续下面步骤进一步分析。
  2. 注意 Memory：Pages/sec、Pages Read/sec 和 Page Faults/sec 的值：操作系统会利用磁盘较好的方式提高系统可用内存量或者提高内存的使用效率。这 3 个指标直接反映了 OS 进行磁盘交换的频度。
     • Pages/sec 值 持续高于几百，可能内存有问题。Pages/sec 值大不一定就表明内存有问题，可能是运行使用内存映射文件的应用导致。
     • Page Faults/sec 越高说明每秒发生页面次数越多，说明 OS 向内存读取的次数越多。此时需要查看 Pages Read/sec 的计数值，该值阈值是 5，超过 5，则可以判断存在内存方面的问题。
  3. 根据 Physical Disk 计数器的值分析性能瓶颈：需要分析 Page Reads/sec 和 %Disk Time 及 Average Disk Queue Length 的分析。如果 Pages Read/sec 很低，同时 %Disk Time 和 Average Disk Queue Length 的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时 Pages Read/sec 并未降低，则是内存不足
• 分析处理器：
  1. 排查 System：%Total Processor Time 计数器的数值：该值体现的是服务器 CPU 的整体利用率，对于多核系统而言，该值体现的是所有 CPU 的平均利用率。
     • 如果该值持续超过 90%，说明整个系统面临着处理器方面的瓶颈，需要增加处理器来提高性能。
     • P.S.：多核下，如果该数据不大，但是各个 CPU 的 负载不均衡，也可以认为是 CPU 产生了瓶颈。
  2. 排查每个 CPU 的 Processor：%Processor Time 和 %User Time 和 %Privileged Time：
     • %Processor Time 很高时，一般 CPU 都阻塞着，但是反之并不亦然。
     • %User Time：非系统内核操作消耗的 CPU 时间（如调用系统本身资源--网络、IO等），若该值较大，可以考虑优化代码、优化算法；如果该服务器是数据库 Server，则该值较大的话可能是数据库的”排序“或是”函数操作“消耗了过多的 CPU 时间，此时可考虑对 DB 进行优化。
     • %Privileged Time：系统内核操作消耗的 CPU 时间
  3. 验证是否系统 CPU 瓶颈：
     • 查看 System：Processor Queue Length 计数器：如果该值大于 CPU 数量的总数 + 1 的时候，说明产生了处理器阻塞。
       
• 分析磁盘I/O：
  1. 如果计算得出每个磁盘的I/O 超过了磁盘本身的I/O能力，则可以确认磁盘是引起瓶颈的因素之一。
  2. 与 Processor：%Privileged Time 联合分析：如果 Physical Disk：%Disk Time 较大，其他值比较适中，则硬盘可能是瓶颈，若几个值都比较大，且持续超过 80%，则可能是内存泄漏。
  3. 分析 Disk sec/Transfer：一般来说，该值小于 15ms 为最佳，15~30ms 为良好，30~60ms 为可接受，超过 60ms 则需要考虑更换硬盘或者更换 raid 方式了。
• 分析进程：
  • 查看 Process：%Processor Time的值：每个进程的该值反映的是进程消耗 CPU 的时间。
  • 查看 Process：%Page Failures/sec 和 Memory：%Page Failures/sec 的比值，过滤出是哪个进程产生的最多的页错误，一般这个进程是需要大量内存的进程，或者是非常活跃的进程（即在压测情况下，就是你要压测的进程）
  • Process：%Private Bytes：该计数器指进程所占有的私有数据（单位字节），即无法与其他进程共享的数据量，可以利用该值来判断应用是否存在内存泄漏。
    • 对于 IIS 进程，可以重点监控下 INetInfo进程的 Private Bytes，如果在压测过程中，该值不断增加，或是在压测结束后，该值仍然处于一个高水平，则说明应用存在内存泄漏
• 分析网络：
  • Network Interface：Bytes Total/sec 为发送和接收字节的速率，可以通过该计数器值来判断网络链接速度是否是瓶颈，具体操作方法是用该计数器的值和目前网络的带宽进行比较。
  • 联合 Processor：%Privileged Time 进行分析：如果 Physical Disk：%Disk Time比较大，其他值比较适中，则硬盘可能是瓶颈，若几个值都比较大，且持续超过 80%，则可能存在内存泄漏。

性能优化的几个策略

• 应用层面：
  • 善用 CDN，缓存，冗余数据，SLB。
  • 如果瓶颈在网络传输，那么需要