.. Kenneth Lee 版权所有 2018-2020
:Authors: Kenneth Lee :Version: 1.0
性能优化的目标问题
昨天和人讨论一个性能优化的问题，我提了一个观点：减少线程的目的是要为指标服务， CS（Context Switch）和Load不是指标，Latency和Throughput才是。
对方反馈说：Latency和Throughput确实是最终目的，但是CS和load可不可以作为达到最终 目标的中间目标来引导调优？
这个问题让我一愣，因为我从来没有想过这个问题。这对我来说，是公理，是多年调优经 验形成的自然感觉，逻辑上为什么是这样的我倒没有想过，所以我通过本文来理一下这个 逻辑。
我的经验，把CS和Load降低，结果Latency和Throughput降低的可能性常常很低。原因包括 ：
大型系统中通常包括不少维护类线程，它们低优先级高频度在后台运行，它们没事的时 候就会跳出来刷存在感，有事的时候不干也行。所以你看着系统的占比很高，但其实这 些占比不影响你多开几个业务。这类线程不一定表现为线程的形态，也可以是线程中的 一个子调度任务
Load这个东西确实表现为当前有多少个线程在等待运行，最优的值是你的核数（或者超 线程数），但如果你有10个核，10个进程都挤在一个核上，其他核全闲着，这个Load也 是10，所以丢开实际情况看Load，也就是个参考，对调优本身的价值是不大的。
CS这种东西，半闲的状态最多，真闲或者高负荷的时候反而就降下来了，我们进行优化 ，保证的是高负荷的时候系统的响应能力，不在乎中间状态，所以，只要满足最终业务 要求，CS高点低点其实是无所谓的
大部分服务器是为高压力设计的，其实低功耗的考量比手机和机顶盒之类的东西少多了 。我们做服务器优化的经验是，合并业务直接关机的效果比搞什么降频，深度Idle有用 多了。手机上合并irq，向下压Load的经验，在服务器上收益很低的，你降低Load了， 也不一定能降功耗，服务器芯片就没有那么多电源域和时钟域。
所以，优化这种事情，目标一定要落在最终的目标上：Throughput不够了？这个包停在哪 个队列里了？谁在处理这个队列？能否变成多个线程？这些线程为什么没有被全力调度？ 优先级不够？调度太多？操作系统误判线程的地位？（比如优先级反转）IO、IRQ处理侵占 了CPU？……能否提高优先级？能否独占核？……这样对着目标去，就很容易逼近，否则常常你 浪费了大量时间，把CS、Load的指标降低了，其他问题又来了，等你把真正的指标降低， 你发现你的CS和Load又回去了，不过是浪费时间。
这个道理和我前一篇（设计的需求问题）说的道理是一样的，做综合决策，要把所有要素 都放上来，然后对着目标去做权衡，这可以少很多纠结。所以确定需求才这么重要，因为 只要需求稍偏一点，结果就会完全不一样。