性能测试通常情况下是个“系统问题”，抛开系统谈论性能通常不会被看做是一件有价值的事情。

 

一个人说“XX模块的性能不好”，这话话我们怎么来解读的呢？

一种情况说的是对于软硬资源的消耗过度，使系统响应速度变慢，也可能我们软硬件本身就不能提供足够的资源。（比如内存泄露，fd没有回收等等导致）

还有一种情况就是在整个系统中这个模块是一个处理瓶颈，他的响应时间会拖累整个系统。这种情况通常还是比较常见的。

前者只会与资源有关，后者只与时间有关。

对于前者，只要这种资源消耗我们能承受，或者资源消耗的增加没有给响应时间带来“无法接受的影响”，我们甚至可以不把他看做一个问题；

对于后者，毋庸置疑，抛开系统谈论响应时间是没有意义的。 工作的目标就是摘出这些“短板”，进行优化，然后让整个系统没有明显的瓶颈。

所以，从这些方面来看，我们的性能测试应该关注些什么呢？

对于单个模块的性能测试——对于响应时间，我们只要测试得出来它的响应时间范围，或者说更好的情况下有一个percentile的图；对于资源消耗，我们只要保证资源的使用不是肆意增长，各种系统资源比较稳定，这就ok了！至于你发现了他的cpu没有被100%利用，或者说，你发现他的内存消耗有几十个G（类似系统可能只有十几个G），再或者说，你发现他的实现虽然线程安全但不是可重入的（以至于系统在软件层次上存在无形的天花板，性能很难提升），这些从计算机系统的角度来讲都可以算是问题（而且也应该把这写问题都记录下来，后面会用得到），但是，这并不符合我们一开始对于“XX模块的性能不好”问题的讨论，所以都可以不把他们当成（这个阶段的）问题。

 

对于系统层次的性能测试——这个过程更像是一个审判官，来决定：到底谁才是真正的性能低下。这个时候进来的模块，理想情况都应该是通过了单独的性能测试的模块（也就是说他的资源使用稳定，而且不会动不动就core dumped）。在系统的性能测试中，我们关注的重点就是系统的短板在哪里，找到了这个就要评估一下几个问题：它在多大程度上拖累了系统（如果他不是性能瓶颈，下一个可能的瓶颈回是谁？会把系统拖慢的什么程度）？我们可以采取哪些办法来优化这个短板？这个时候上面的一些信息就用到了，比如：你可以考虑把他改成“可重入的”，或者采取一些空间换时间的方法，来提升他的性能。当然也有可能没有办法提升，这个时候就只能考虑能不能把他做成多个节点的了。

 

对了，补充一下，上面都是对于“分布式系统”性能测试的思考。如果被测对象是一个被频繁使用的common库，那么，对于性能的追求可能是无极限的，这种情况不在上述的讨论范围之内。