曾去一家公司面试，他们就问到我有没有用过什么性能瓶颈的测试工具，当时还真没去好好了解。回来后搜索了一下，发现Interl公司的VTune是一款不错的软件。不过要做到像VTune这样细致的，似乎很难。在我的经验里，要定位到哪个语句最消耗性能，这个似乎并不是很难，而往往是把你把消耗性能的代码去掉，它也提升不了多少，或者是最消耗性能的代码就是系统的最核心的操作，你根本无法去掉，甚至已经没有优化的余地了。

有的系统在部署的时候，CPU占用率大约60%，内存使用率也不过50%，而再多部署几个相同的进程上去的时候，性能却得不到提高。原本每个进程可以处理5MB的流量，当部署更多的时候，每个进程处理的流量却降低到3MB，CPU和内存利用率更低，如此形成恶性循环。我想对待这样的情况，即使使用VTune测试，也不会找到真正的瓶颈所在。虽然我没有机会去解决这个问题，但我想它极有可能是由于代码中没有注意性能瓶颈的要素，比如在核心处理过程中夹杂着IO，导致线程频繁切换，最终形成的有力使不上的局面。

一、性能指标

在实时数据处理过程中，以下三个要素往往是衡量系统性能高低的重要指标。

1、CPU占用率

这个往往是领导非常关心的问题，因为涉及到硬件成本问题。如果你的一个进程占满几个CPU资源，那其他进程怎么办?放哪里?领导的想法都是尽可能地使用较少的服务器，部署较多的服务，减少购买服务器的成本，所以不要用霸占CPU资源的手段来提高性能。实时处理不但时间很重要，空间也是一个不可忽视的因素。这里再重复提一下，“经过试验，偶得出的结论是，没有数据需要处理时，才可以短暂地sleep一下，有数据时不应该有任何停顿”，这样基本可以在性能和CPU利用率之间达到一个比较合理的平衡。

我设计的系统都是流水结构，并且一般都符合一个生产者与一个消费者模式，在这种情况下，我最开始并没有将线程sleep，而是监视生产者与消费者共享的一个FIFO的push和pop过程，发现不可以pop的时间远远大于不可以push的时间，也就是说没有数据的时间远远大于可装入的时间，即消费者速度大于生产者速度。在这种情况下，很有必要将消费者sleep一下，以释放CPU资源。

2、内存消耗

在现在64位的机器里，内存的成本问题似乎显得不那么重要了，但是为了抵御波峰，我们需要开辟的内存往往超出我们的想象，有效利用内存在调试阶段就显得很有必要了。至于如何提高内存有效使用率将在后续专题讨论。

3、流量

实时流量则是最大的性能指标了，只要在系统的入口和出口流量相当，中间过程无overflow就可以了，一般使用流量计实时显示出来。

二、测试手法

在国内估计没有公司能支撑一个团队开发像VTune这样软件，当然我也不可能有这样的机会。曾在领导的要求下，使用windows的QueryPerformanceCounter函数做分布式耗时测试，即通过这个API，把每个核心操作的耗时统计下来，然后比较哪个操作最耗时。做了好几次，每次都花了不少时间，可得出来的结果是核心操作的耗时差异不大，而且是远远小于程序运行的总时间。至于这样的测试，为什么会得出这样的结果，结果是否正确，结论是什么，我不想过多地讨论，但在后来的工作中，我按照自己的思路，注意我在《实时数据处理性能瓶颈》一文中的要点，将一个前端采集系统由原来的30MB提高至4Gb。其实100Gb也无所谓，因为我是并行结构。

我没有VTune这样牛X和细致，也不想使用所谓的耗时分布测试手段，但我发现我做到以下两点，基本就可以将性能提升一到两个数量级。这两点的测试手法都是把流量计嵌入到代码中，实时地显示出来。

1、核心流水业务节点测试

由于这个前端系统已经存在，所以在重构这个系统时，我需要一步一步地来移植已经存在的业务逻辑。每当我完成一个核心处理的移植后，我就进行该段核心业务的性能测试，从而排除后续过程对该段业务过程的影响。在测试前，我首先会将夹杂在逻辑运算中的IO剔除。如果这个地方能满足性能要求，就继续测试下一个流程;如果不行，则会按照《实时数据处理性能瓶颈》中的要点，逐一优化。

在这一测试过程中，我会监测4个性能指标：

1) 入口流量 2) 出口流量 3)FIFO溢出次数 4) FIFO利用率

2、串行逻辑测试

当上一测试不能满足性能要求后，我会逐一排查其性能瓶颈，将这个核心业务处理的线程分解，理清里面究竟含有几个过程，然后再在里边嵌入流量计，看看瓶颈究竟出在什么地方。当然也会使用排除法，仅运行前面几个过程，尽量缩小范围。

写到这，就发现测试需要注意的两个事项就是：

1)降低系统的耦合度 2) 排除异常干扰因素

三、现象与对策

在测试与调试过程中，FIFO的溢出异常关键，因为我做的系统中，数据丢失是绝对不可以接受的。其一般表现为两种状态：

1、快速溢出

快速溢出则说明该过程是目前这个线程负载不了的，解决方法一般有两种方式，一个就是优化其内部处理过程，提升性能;如果已经优化完了，还不能满足，则需采用并行模式，在上一过程进行数据分流，采用两个相同的线程同时并行地处理该过程。

2、偶尔溢出

FIFO在某段时间不溢出，某个时间段溢出，表现的不是很稳定，这一般是由于数据源突然流量增大，FIFO抵御不了这样的波峰，而造成溢出。如果你监控了FIFO的利用率，你就会发现在波峰的时候，FIFO的使用率也非常高，在某个时间就顶不住了。这种情况你只需要将FIFO的size加大就可以了，一直加大到它不溢出为止。当然这有个必要条件就是，你最好将FIFO优化，努力提升其有效使用率，避免FIFO中有大量的空闲区域。

四、性能指标的监测方式

性能指标一般是在核心处理过程中计算出来的，如果在核心处理过程中输出，势必影响其效率。我的方法是这样的：

1) Windows平台

在核心处理中，将性能指标实时(也不是完全实时，间隔一定的时间)地计算出来，保存在这个核心处理对象中;主线程主要负责UI,一般比较悠闲，所以让主线程去读取核心处理对象的性能指标，并显示在UI上。一写一读，两个线程没有冲突，如此可以解放核心线程的性能指标IO操作。

2) Linux平台

Linux采用同样的思想，只不过主线程不是将性能指标实时地显示在UI上(因为Linux多为后台运行)，而是写入到一个共享内存，由另外一个进程在需要的时候，实时显示这些性能指标，类似top命令。