QPS概念扫盲性能优化的常见招式有哪些( 二 ) _怎么优化

为了剖析最优线程数和资源之间的关系，下面我讲一步步分解，让大家理解。
深度理解瓶颈资源
为了理解瓶颈资源，假设一个业务场景：
下面通过对程序运行态通过图表的方式是呈现出来，便于大家理解瓶颈资源、多资源情况下的线程调度。
以5ms作为一个时间帧。
第1个5ms如下
cpu同时可以运4个线程，因此请求11 ， 21,31,41执行，其余5个请求，等待CPU资源。
第2个5ms如下
cpu同时可以运4个线程，其余5个请求，等待CPU资源。
第3个5ms如下
第4个5ms如下
第5个5ms如下
通过快照图，我可以看到什么？
一个多资源的程序中：对资源的争用表现为对瓶颈资源的争用，性能情况会受制于瓶颈资源。
瓶颈资源可以用水桶原理来解释，如下图。
基于上述对线程、瓶颈资源的梳理，我们很容易提炼出QPS的理论公式，大家可以看下面的公式，如果觉得烧脑，可以多看几遍。
深入理解QPS公式
最优线程公式：
1、最优线程数量=线程总时间/瓶颈资源时间 * 瓶颈资源并行数
2、一个线程1S可以处理的请求数
3、 1000/线程总时间
QPS公式1：QPS =最优线程数量* 1000/线程总时间；
QPS公式2：QPS=1000/瓶颈资源时间 * 瓶颈资源并行数。
这个公式里隐含了一些有趣的解释，大家可以去揣摩下。
性能压测
——从理解瓶颈到如何识别瓶颈
前面讲的都是理论，很多很多理论，下来大家可以花些时间理解。主要目的是让大家对性能有个可量化的指标衡量，知道指标了，那么下一步就是讲如何获得这些指标，如果通过这些指标发现问题。
接下来的章节，如何识别瓶颈资源，常用的方式是压测，下面是压测模型图（没有讲怎么使用jmeter压测等）。
压测模型抽象
性能压测是有方法，有模式，有目标的。如何对压测进行管理，如何创造压力，如何准备被测系统，如何准备压测数据，如何收集压测数据，如何分析压测数据。是要进行稳定压测，还是要进行瓶颈压测等等。
性能压测是一件很专业的事情，对于压测，理解压测的组成环境是很重要的，有的时候，压测的环境就是压测瓶颈。
压测环境组成
这里讲两个环境：
1、压力机环境：不要认为压不上去了就是被测系统的问题，曾经也遇到过jmeter处理压测响应数据的性能瓶颈，导致一致压不上去。
2、依赖系统/数据的影响：举个例子比如集群部署后，线上A调用B应用， A是100台， B是1000台；但是线下性能实验室A和B是1：1关系。 1：1压测出来的数据是否就是线上的数据呢，这里是有一个问号的。
压测需要注意的一些事项：

理解环境
压测环境和线上环境的不同
避免压测环境的不同造成压测结果的不可行
吞吐量和响应时间的取舍和平衡
确定合理的性能预期值
适可而止
不做过度的优化，在性能和其他因素（架构，可维护性）等的平衡
选取合适的压测场景设计用例
天花板
充分利用资源
不过度使用资源

从识别瓶颈到如何进行优化
内容可以见下图
如何识别瓶颈？永远也不会废的方法，隔离法和替换法。当你觉得对哪一块怀疑（CPU、IO、线程、压力机、外围系统）的时候，可以快速的使用这些方法识别。
比如你可以使用mock ，挡板，更换机器。
这两个方法很简单，比冥思苦想有用多了，所以性能优化，不要把自己逼疯了。
优化手段，可以见图中方式，性能优化有一定招式，但是结合具体场景后，有各种取舍，不要一味生搬硬套。
Q&A:
Q1 什么时候需要优化性能？需要提前考虑么？
我认为性能的问题是一个技术人员、架构师骨子里的东西（需要提前考虑）；但是实施的步骤是根据你的业务场景、业务量、业务增量、系统当前的容量，系统的扩展性等问题来考虑（比如是否可以水平扩展应对等），不用做过渡的超前设计。
Q2 上图中的N+1那个N指什么？
N就是对CPU的核数，这里只是理解了很多人/或者网上提高的一些经验值，这些经验值有可能是在没有考虑多资源的情况下的值，但是有可能你的系统就不是一个CPU密集运算性系统。
Q3 比较感兴趣耗时统计工具，是开源的么？有移动端的统计工具么？