例如，在100个并发聚汇分流软件用户下（以一定的密度发出请求）是90%的CPU使用率，那么150个并发用户怎么办？所以，一定的余量是需要考虑的。这些余量至少为系统做进一步改进争取了时间。在这个实例中，我们假设50%的CPU使用率是可以接受的。

     除了使用率的问题，我们也需要关注CPU在做什么。假设不存在异常的循环，那么CPU使用率过高，是不是说明业务计算任务过于繁重（换句话说，过于密集）了呢？一般情况下是这样的。当然，如果我们仔细观察CPU使用率的曲线，也许可以想到更多。首先，那条曲线的波峰点，不是某个时刻CPU的状况，而是在一个采样间隔内CPU用于计算与等待的时间比。所以，即便使用聚汇分流软件那个波峰点上的堆栈信息，也不能马上认定那个堆栈中正在运行的方法就是一个耗时的计算，而这个错误的思路曾经误导了我们。

     其次，由于我们采用了多核处理器，而又没有使用并行GC来收集垃圾对象，波谷点是不是代表了一次GC？我们想象不出其他造成CPU等待的原因，由于WebSphere使用了NIO技术，所以IO等待应该不成问题，执行sar 命令后的输出信息，也可以证实这一点。

     不管怎样，我们主要的怀疑在于两点。第一，业务计算太多；第二，GC过于频繁。稍后，我们会涉及GC的问  题。现在先看看太多的业务计算。在单用户下，一些复杂的事务需要3s的响应时间。在这个时间段内，CPU真正用于计算的时间是多长呢？

     这很关键，每个人都很想知道答案。但是，大多数的Java Profiler工具却没法给出，原因在前面已经说过了。也许为了解决大连读屏软件开发这个问题，最好的办法是在程序中输出时间日志。可是这样做既麻烦又无法快速定位，效率非常低。

     真实的运行时间是整个性能分析的关键，也许将来我会考虑在这方面做些工作。

     我们分析了那些复杂的事务。这些事务中的确包含了大量的业务计算。尽管我们尝试做了一些简化业务逻辑的工作，但基本上没有什么重要的线索，最终不得不放弃了这方面的努力。

致远服软认为：http://www.soft8.com.cn/前面我们提到了聚汇分流软件使用频繁的问题。其实，这个问题与内存的使用紧密相关。下面，我们不妨先来看看内存的状况。

     通过JConsole连接到远程的JVM，我们看到了一根糟糕的内存使用曲线。在一个复杂事务工作时，竟然使用了200M以上的内存。最严重的情况下，点击页面上的一个按钮，就会导致一次Full GC。这完全不能让人接受。