提高系统的处理核心数

提高系统的处理核心数就是增加系统的并行处理能力。

比如可以把系统的处理核心数增加为两个，并且增加一个进程，让这两个进程跑在不同的核心上。这样从理论上，你系统的吞吐量可以增加一倍。

这种情况下，吞吐量和响应时间就不是倒数关系了，而是：

吞吐量=并发进程数/响应时间

计算机领域的阿姆达尔定律（Amdahl’s law）是吉恩·阿姆达尔在1967年提出的。它描述了并发进程数与响应时间之间的关系，含义是在固定负载下，并行计算的加速比，也就是并行化之后效率提升情况，可以用下面公式来表示：

(Ws + Wp) / (Ws + Wp/s)

• Ws表示任务中的串行计算量
• Wp表示任务中的并行计算量
• s表示并行进程数

可推出另外一个公式：

1/(1-p+p/s)

s还是表示并行进程数

p表示任务中并行部分的占比

当p为1时，也就是完全并行时，加速比与并行进程数相等；当p为0时，即完全串行时，加速比为1，也就是说完全无加速；当s趋近于无穷大的时候，加速比就等于1/(1-p)，你可以看到它完全和p成正比。特别是，当p为1时，加速比趋近于无穷大。

我们似乎找到了解决问题的银弹，无限制地增加处理核心数就能无限制地提升性能？

随并发进程数的增加，并行的任务对于系统资源的争抢也会愈发严重。在某一个临界点上继续增加并发进程数，反而会造成系统性能的下降，这就是性能测试中的拐点模型。

并发用户数处于轻压力区时，响应时间平稳，吞吐量和并发用户数线性相关

并发用户数处于重压力区时，系统资源利用率到达极限，吞吐量开始有下降的趋势，响应时间也会略有上升。这个时候，再对系统增加压力，系统就进入拐点区，处于超负荷状态，吞吐量下降，响应时间大幅度上升。

所以评估系统性能时通常需要做压测，找到系统的“拐点”，从而知道系统的承载能力，也便于找到系统瓶颈，持续优化系统性能。

减少单次任务响应时间

首先看你的系统是CPU密集型还是IO密集型的，不同类型的系统性能优化方式不尽相同。

CPU密集型系统中，需要处理大量的CPU运算，那么选用更高效的算法或者减少运算次数就是这类系统重要的优化手段。比方说，如果系统的主要任务是计算Hash值，那么这时选用更高性能的Hash算法就可以大大提升系统的性能。发现这类问题的主要方式，是通过一些Profile工具来找到消耗CPU时间最多的方法或者模块，比如Linux的perf、eBPF等。

IO密集型系统指的是系统的大部分操作是在等待IO完成：

• 磁盘IO
• 网络IO

大部分都属于IO密集型，比如数据库系统、缓存系统、Web系统。这类系统的性能瓶颈可能出在系统内部，也可能是依赖的其他系统，而发现这类性能瓶颈的手段主要有两类：

采用工具

Linux的工具集很丰富，完全可以满足你的优化需要，比如网络协议栈、网卡、磁盘、文件系统、内存，等等。这些工具的用法很多，你可以在排查问题的过程中逐渐积累。除此之外呢，一些开发语言还有针对语言特性的分析工具，比如说Java语言就有其专属的内存分析工具。

监控来发现性能问题

在监控中我们可以对任务的每一个步骤做分时的统计，从而找到任务的哪一步消耗了更多的时间。

找到了系统瓶颈，如何优化呢？

如果是数据库访问慢，那么就要看是不是有锁表的情况、是不是有全表扫描、索引加得是否合适、是否有JOIN操作、需不需要加缓存

如果是网络的问题，就要看网络的参数是否有优化的空间，抓包来看是否有大量的超时重传，网卡是否有大量丢包等。

比如做广告检索遇到的问题，倒排索引存在Redis，每次都要请求Redis，但是并发时，Redis连接数太大，甚至打开文件数过大，后采用Redis连接池，Redis连接数得到控制，而且响应更快，后来随着并发数的增大，连接池资源耗尽，而且Redis也有并发限制，数据传输导致大量占用带宽，响应时间更久，因此，又使用了本地缓存，每次请求先请求本地缓存，找不到再请求Redis，缓存到本地，缓存更新时通过消息队列来通知程序更新本地缓存，这样节省了大量的和Redis之间的请求耗时和带宽占用，性能有了数倍的提升。

总结

高并发：高性能（响应时间）、高可用（down机、故障、维护）、可扩展（应急扩容）

响应时间（平均值、最大值、分位值），响应为1s，吞吐量为每秒1次，响应缩短到10ms，吞吐量上升到每秒100次，从用户体验来说：200ms分界点，1s为另一个分界点，健康系统的99分位值的响应时间控制在200ms以内，不超过1s的请求占比要超过99.99%

高并发下的性能优化手段：

1.提高系统的处理核心数（吞吐量=核心数(并发进程数)/响应时间(s)）

但并非无限增加核心数就可以增加吞吐量，随着进程数增加，并行的任务对于资源的争夺也增加，在某

个临界点，进程增加导致系统的性能下降，这就是性能测试中的拐点模型，所以在评估系统性能时，需要做压力测试，找到拐点

2.减少单次任务响应时间

cpu密集型：优化算法

io密集型：1.采用工具，linux的工具集

2.通过监控，对任务的每一个步骤做分时统计，从而找到任务中哪一步小号消耗了更多的时间