例如，在100個并發(fā)聚匯分流軟件用戶下（以一定的密度發(fā)出請求）是90%的CPU使用率，那么150個并發(fā)用戶怎么辦？所以，一定的余量是需要考慮的。這些余量至少為系統(tǒng)做進一步改進爭取了時間。在這個實例中，我們假設50%的CPU使用率是可以接受的。
除了使用率的問題，我們也需要關注CPU在做什么。假設不存在異常的循環(huán)，那么CPU使用率過高，是不是說明業(yè)務計算任務過于繁重（換句話說，過于密集）了呢？一般情況下是這樣的。當然，如果我們仔細觀察CPU使用率的曲線，也許可以想到更多。首先，那條曲線的波峰點，不是某個時刻CPU的狀況，而是在一個采樣間隔內CPU用于計算與等待的時間比。所以，即便使用聚匯分流軟件那個波峰點上的堆棧信息，也不能馬上認定那個堆棧中正在運行的方法就是一個耗時的計算，而這個錯誤的思路曾經誤導了我們。
其次，由于我們采用了多核處理器，而又沒有使用并行GC來收集垃圾對象，波谷點是不是代表了一次GC？我們想象不出其他造成CPU等待的原因，由于WebSphere使用了NIO技術，所以IO等待應該不成問題，執(zhí)行sar 命令后的輸出信息，也可以證實這一點。
不管怎樣，我們主要的懷疑在于兩點。第一，業(yè)務計算太多；第二，GC過于頻繁。稍后，我們會涉及GC的問 題?，F在先看看太多的業(yè)務計算。在單用戶下，一些復雜的事務需要3s的響應時間。在這個時間段內，CPU真正用于計算的時間是多長呢？
這很關鍵，每個人都很想知道答案。但是，大多數的Java Profiler工具卻沒法給出，原因在前面已經說過了。也許為了解決大連讀屏軟件開發(fā)這個問題，最好的辦法是在程序中輸出時間日志?？墒沁@樣做既麻煩又無法快速定位，效率非常低。
真實的運行時間是整個性能分析的關鍵，也許將來我會考慮在這方面做些工作。
我們分析了那些復雜的事務。這些事務中的確包含了大量的業(yè)務計算。盡管我們嘗試做了一些簡化業(yè)務邏輯的工作，但基本上沒有什么重要的線索，最終不得不放棄了這方面的努力。
致遠服軟認為：http://www.soft8.com.cn/前面我們提到了聚匯分流軟件使用頻繁的問題。其實，這個問題與內存的使用緊密相關。下面，我們不妨先來看看內存的狀況。
通過JConsole連接到遠程的JVM，我們看到了一根糟糕的內存使用曲線。在一個復雜事務工作時，竟然使用了200M以上的內存。最嚴重的情況下，點擊頁面上的一個按鈕，就會導致一次Full GC。這完全不能讓人接受。
