前两天公司一次关于性能测试的分享，去听了一半，下面几位大牛说的云云 说实话，没什么感觉，感觉有点虚（估计是我太水了吧，呵呵 毕竟人家是高P） 倒是剑魔童鞋说的感觉很实在，其中有一张很有意思的一幅图，如下：
在这里简单说一说~
图中是一个坐标图，简单说，
横坐标：表示“瓶颈资源”的消耗率（利用率）；
纵坐标：表示请求的并发量，其实进一步说，可以理解为服务器的请求压力了。
什么是“瓶颈资源”？从字面意思差不多也可以知道的，就是限制一个 系统/服务器 最大处理能力的那个元素，比较常见的如CPU、内存、网络线路等。
先看图中的“期望值”，通常是我们期望达到的一个情况，随着并发量/请求量的增加，瓶颈资源的消耗也越来越大。然后就有下面几种情况出现：
1、事实情况是跟“原始2”一样，请求量/并发量在还没有达到期望值的情况下，“瓶颈资源”的消耗就已经超过50%了（按照运维的标准，瓶颈资源的消耗超过50%的时候就会发警报，需要引起注意，可能会引起系统不稳定等，当然不同公司的标准可能不一样），如下来看，可能无法满足实际线上需求，这个时候就需要进行调优了，比如如果这里系统处理速度是瓶颈资源，那么就需要扩容一台机器，分流处理，这样就可以达到“调优2”的效果了，从而满足线上需求；
2、接着上面的举例，如果发现线上扩容了一台机器后，实际情况却是“调优1”，而不是“调优2”，是不是很奇怪，难道之前的性能测试结果是错的？不一定，这个时候其实更多的可能是，系统的“瓶颈资源”发生的变化，如果之前的“瓶颈资源”是系统处理速度，那么在我扩容了一台机器后，如果“瓶颈资源”变成了DB，那么如果不对DB进行拆分或者扩容等，这个时候即使再增加机器，而实际情况却会像“调优1”的后半段一样，走下滑趋势，因为“瓶颈资源”已经不再是处理速度了，而是DB。限制整个系统的瓶颈在DB了。
3、假设一个系统主要功能是做一些IO操作，而这些IO操作需要大量消耗内存（或者系统的主要功能是网络上接受信息，然后再发送出去，这些消息都是存储在内存里的），这就涉及到一边在增加内存队列，另一边在不停的发送消息来消耗这些队列，当网络接受到的内容不多（并发量/请求量 低）的时候，发送速度能力 > 接受能力，随着请求量的增加，发送量也会线性增加，但是当 发送速度能力 < 接受能力，就会让内存队列越来越大，后面随着时间和并发量的增加，系统的整体性能就会出现一个下降的趋势（内存是瓶颈资源体现出来了），如图中“原始1”，这个时候我们增加内存，当然系统的整体性能会变好，但是因为这种模式的特殊性，当并发量持续增加，性能曲线还是会像“原始1”一样开始下滑，只是下滑的起始点高一点，由此可见，这个时候一味的通过扩容“瓶颈资源”来提高性能并非万能的，这个时候需要考虑处理的方式上做一些改变，必然换一种处理方式等。
其实发现，这幅图能发现的远远不止这些，细细体会，还能得出更多的提示和想法的~
厄，一点了，睡觉、、、