為什麼一些以前的技巧無法用於新版本
在多個 IBM® WebSphere Application Server V7 研討會上，我在過去幾個月一直在為客戶做演講，性能總是一個流行的話題；具體來說，很多人都想知道如何調試獲得最優性能。鑒於在這些研討會中該話題的很熱門以及對如何調試和調試什麼大家普遍存在一定誤解，我認為有必要簡單介紹一下應用服務器調試中有哪些准則。
別調台！
即使您沒用過這個短語，也一定聽說過它。幾年前，電視和廣播上廣告開始時經常出現這個短語。有了數碼接收器之後，我們就不再使用調節旋鈕來調電視或廣播了（除非您的電視或收音機很老），但是在調試 WebSphere 應用服務器時這個短語卻是個很好的指導。原因是經過一段時間，隨著 WebSphere 應用服務器運行時不斷改進，各種線程和連接池的默認大小變小了，因為與之前的運行時實現相比，執行相同（或更多）工作量需要的這些共享資源變少了。
WebSphere 應用服務器運行時中這種改進的一個例子就是 Web 容器線程池。在 WebSphere Application Server V6.x 之前，在並發客戶端連接數和 Web 容器線程池中的線程數之間存在一對一的映射。換句話說，如果 50 個客戶端在訪問一個應用程序，那麼需要 50 個線程來服務這些請求。在 WebSphere Application Server V6.0 中由於引入了 NIO（本機 IO）和 AIO（異步 IO），這種情況有了變化，它使連接管理能夠由少數線程來處理而實際工作也能夠由較少的線程來處理。
在最近的一個客戶互動中，我發現公司誤認為 “池大小越大，性能就越好” 並將池的大小改得比默認值大。在測試運行中，通過 IBM Tivoli® Performance Viewer 觀察了實際線程使用和連接池使用情況之後，我能夠通過實際降低 Web 容器線程池和 JDBC 連接池的大小將性能提高了 30%。降低池大小意味著 WebSphere Application Server 在管理運行時資源方面的開銷也會減少；在這種情況下，不需要線程和連接對象，因此可以釋放 CPU 和內存用於處理應用程序請求。
一定要調試 JVM！
這不是電視和廣播中的常用語，但是這可能是您通過 WebSphere 應用服務器可以進行的最重要的調節了。正確調節 JVM（最常見的只是根據工作負載正確調整 JVM 大小）通常會在 WebSphere 應用服務器中帶來單一調試所能獲得的最大性能改進。
WebSphere 應用服務器中的默認堆大小是初始堆大小 50 MB，最大堆大小 256 MB。這些值對於您的環境而言可能不是最佳的，但是它們是保守值，選擇它們可以避免 過度使用內存 的問題。結果是您很可能會增加 JVM 大小（假設您有足夠的物理內存用於 JVM）。
正確調整對大小需要啟用 verbosegc（verbose garbage collection statistics，詳細垃圾回收數據統計），運行測試，然後分析 verbosegc 輸出結果來確定如何調整堆大小。您可以使用 IBM Pattern Modeling and Analysis Tool for Java™ Garbage Collector (PMAT) 來分析 verbosegc 輸出結果或使用 IBM Support Assistant 附帶的 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer 來分析。
就堆大小而言：
Java 堆大小應該調整為平均內存使用的 40-70%。
垃圾回收應該間隔超過 10 秒。如果垃圾回收每 10 秒發生超過一次，或者堆利用率超過堆的 70%，那麼可以考慮增加堆大小。
垃圾回收持續時間應不超過 1-2 秒。如果發現垃圾回收持續時間超過了 1-2 秒，那麼這是堆過大的信號，或者說明 “nursery” 太大了（如果在使用分代式垃圾回收）。同樣，內存使用少於 40% 則說明堆太大了。
垃圾回收占用的總時間應該不超過測試持續時間的 15%。在測試中花費超過 15% 的時間進行垃圾回收通常是各種因素造成的。
說到測試，您的測試長度應該最少為 10-15 分鐘以便 JVM 能夠優化字節碼和運行時達到穩定狀態。測試時間短於此，結果的准確性可能會受到容器啟動和線程優化的影響。
關於 JVM 調節的最後一點建議是不要忘記調節節點代理和部署管理器的 JVM。因為這兩個 WebSphere 應用服務器網絡部署組件都是 JVM，上述針對應用服務器根據工作負載和垃圾回收調整堆大小的建議也適用於這裡。能夠影響這些 JVM 工作負載的因素包括應用服務器的數量、單元的大小、配置變更的頻率以及這些配置變更的大小（特別是應用程序部署）。
底線：要評估節點代理（或部署管理器）所需的內存，需要分析堆使用情況和代表時間段內的垃圾回收周期，對於這兩個組件來說，這還應該包括至少一個應用程序部署。應用程序部署，尤其是大的 EAR 文件，可能導致 在部署管理器和節點代理 JVM 中創建大量對象，這也提供了一些方法來減少對象創建，從而加速應用程序部署。
未經測試不要放松 WebSphere 隊列
WebSphere 應用服務器部署是 一系列隊列，最好只允許能力范圍內的工作量進入隊列。這會避免任何組件的超載導致性能下降，我上面介紹的將 Web 容器線程池和連接池大小提高到超過 WebSphere 應用服務器處理請求所需值的客戶就存在這種情況。
另外要遵守以下原則：運行測試來確定吞度量曲線並仔細監控所有組件的資源使用情況：網絡、所有服務器上的 CPU、磁盤等等，以便確定瓶頸在哪裡。
改進各種組件的 WebSphere 應用服務器運行時實現的一個負面作用就是過去 WebSphere 應用服務器可能在隊列網絡中出現瓶頸，更多新的運行時改進可能導致其他資源受限；例如，數據庫服務器中的 CPU，因為現在 WebSphere 應用服務器可以更快速地向數據庫服務器提供請求。
這裡最重要的信息是如果調整了以前版本的 WebSphere 應用服務器，改變了默認池大小，您可能要重新查看這些變更並確保以前有助於性能提升的變更在新版本的 WebSphere 應用服務器中不要降低性能。
結束語
WebSphere 應用服務器信息中心會不斷向您提供關於調節 WebSphere 應用服務器各個方面（JVM、線程、連接池和緩存等）以及操作系統的最新信息。可以花些時間研究信息中心中關於您所使用的 WebSphere 應用服務器版本的建議。也可以用一點時間溫習一下性能調優方法，這不僅在信息中心中提供介紹，在 Java 網站的性能分析 中也提供詳細介紹，這是我所知道的關於調優方法的最為全面的參考資料。
