03 如何提升系统性能？

高并发系统设计的三大目标：高性能、高可用、可扩展
高并发承担更大的流量。性能反映了系统的使用体验。可用性表示系统可以正常服务用户的时间

性能优化原则

• 性能优化一定不能盲目，一定是问题导向的。脱离了问题，盲目的提早优化增加系统的复杂度，也因为某些优化可能会对业务上有折中的考虑，会损伤业务。
• 性能优化遵循“二八原则”，即你可以用20%的精力解决80%的性能问题。所以我们在优化过程中一定要抓住主要矛盾，优先优化主要的性能瓶颈点。
• 性能优化要有数据支撑。在优化过程中，要时刻了解你的优化让响应时间减少了多少，提升了多少吞吐量。
• 最后，性能优化的过程是持续的。高并发系统通常是业务逻辑相对复杂的系统，那么在这类系统中出现的性能问题通常也会有多方面的原因。

性能的度量指标

一般来说，度量性能的指标是系统接口的相应时间，但是单次的相应时间是没有意义的，需要知道一顿时间的性能情况是什么样的。多以，我们需要收集这段时间的响应数据，然后依据一些统计方法计算出特征值，这些特征值就能够代表这段时间的性能情况。我们常见的特征值有以下几类。

• 平均值，对于度量性能来说只能作为一个参考。
• 最大值。
• 分位值，分位值有很多种，以90分位为例，我们把这段时间请求的响应时间从小到大排序，加入共有100个请求，那么排在第90位的响应时间就是90分位值。分位值排除了偶发挤满请求对于数据的影响，能够很好的反映这段时间的性能情况，分位值越大，对于慢请求的影响就越敏感。
  分位值是最适合作为时间段内，响应时间统计值来使用的，在实际工作中应用最多。除此之外，平均值可以作为一个参考值来使用。

之前提到，脱离了并发来谈性能是没有意义的，我们通常使用吞吐量或者响应时间来度量并发和流量，使用吞吐量地方情况会更多一些。

从用户体验的角度来看，200ms是第一个分界点：接口的响应时间在200ms之内，用户是感觉不到延迟的。1s是另外一个分界点，响应时间在1s以内时，感受是可以接受的。超过1s之后用户会有明显等待的感觉，等待时间越长，体验越差。所以响应时间通常要控制在200ms以内，而不超过1s的请求占比要在99.99%以上

高并发下的性能优化

主要有两种思路：一种是提高系统的处理核心数，另一种是减少单次任务的响应时间。

• 提高系统的处理核心数(此处省略公式推导过程)。能不能无限制的增加处理核心数，无限制的提升性能，从而提升系统处理高并发的能力呢？很遗憾，随着并发进程数的增加，并行的任务对于系统资源的争抢也会愈发严重。在一个临界点上继续增加并发进程数，反而会造成系统性能的下降，这就是性能测试中的拐点模型。
  image
• 减少单词任务响应时间
  想要减少任务的响应时间，首先要看你的系统时CPU密集型还是io密集型。CPU密集型系统中，需要处理大量的CPU运算，那么选用更高效的算法或者减少运算次数就是这类系统重要的优化手段。比如说系统的主要任务是计算hash值，那么这时选用更高性能的hash算法就可以大大的提升系统的性能。发现这类问题的主要方式，是通过一些Profile工具来找到消耗CPU时间最多的方法或者模块，比如Linux的perf，eBPF等。

IO密集型系统指的是系统的大部分操作是在等待io完成，这里的IO指的是磁盘IO和网络IO。我们熟知的系统大部分属于IO密集型，比如数据库系统、缓存系统、web系统。这类系统的性能瓶颈可能出现在系统内部，也可能是依赖的其他系统
，而发现这类性能瓶颈的手段主要有两类。
1.采用工具，Linux的工具集很丰富，完全可以满足你的优化需要，比如网络协议栈、网卡、磁盘、文件系统、内存等等。这些工具的用法很多，你可以在排查问题的过程中逐渐几类。
2.可以通过监控来发现性能问题。

如果找到了系统的瓶颈点，我们要如何优化呢？优化方案会随着问题的不同而不同。比如说，如果是数据库访问慢，那么就要看是不是有锁表的情况、是不是有全表扫描、索引加的是否合适、是否有join操作。需不需要加缓存等等；如果是网络问题，就要看网络的参数是否有优化空间，抓包来看是否有大量的超时重传，网卡是否有大量丢包等。

业务价值->承载高并发->性能优化。一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，性能在需要的地方是No.1，但不需要的地方可能就是倒数第一.