原文：http://www.talkwithtrend.com/Article/207511
池（Pool）是WebSphere中最常涉及的概念之一。從網絡、Web 服務器、Web 容器、EJB 容器，一直到數據源，每一個環節都線程池、連接池的影子。要想恰當配置這些池的大小，首先要了解漏斗模型。
通常，WebSphere應用中的一個請求到達服務器，到真正開始處理，要經過一系列的連接池。廣域網上可能有大量的並發用戶同時訪問Web服務器，Web服務器上同時活動（Active）的連接可能高達10000個。但Web服務器到應用服務器（Web容器）的連接池大小可能只有200。Web容器到EJB容器的連接池更小，可能是80。然后，經過數據源（Data source）到數據庫的連接最大可能只有25個。從Web服務器的連接池到數據庫的連接池尺寸逐漸變小，像一個漏斗（funnel），所以稱為漏斗模型。
IBM 000-253中有這么一道題：
According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?
A Web Server=75, Web container=75, Datasource =25
B Web Server=75, Web container=50, Datasource =25
C Web Server=50, Web container=50, Datasource =50
D Web Server=25, Web container=50, Datasource =75
根據漏斗模型，那么很顯然應該選B。
那么實際生產環境中就如此依樣畫葫蘆就可以了么？后面的池一定比前面的小么？如果當前性能不行，增大池的大小就能提高么？
絕沒有那么簡單。后面的池小於前者，比如數據庫連接池小於web線程池，默認的假定是：並非每個JSP和Servlet都需要訪問數據庫。如果你的應用是數據庫密集型的應用，基本上每個JSP和Servlet都需要訪問一次或多次數據庫，而且系統中還有一些不經過jsp或Servlet的后台進程。那么數據源的連接池就必須大於web容器線程池，否則會報無法得到連接的錯。
下面按照我的經驗講述一下每層池大小設置值
對於Web服務器
IBM HTTP Server的優化就是對Apache的優化。一般需要調整httpd.conf中如下參數：
MaxClients：用來定義Web服務器可以同時支持的最大並發連接數或並發用戶數，默認值是600。這個值需要根據你所希望的同時支持的並發用戶數來設置，一般是峰值的120%。當然這個值不能設的太大，畢竟Apache吃內存也是很厲害。我遇到的項目一般是不用調整的，大家可以根據實際負載動態的調整MaxClients。
將 IBM HTTP Server 配置為顯示狀態頁面：
- 編輯 IBM HTTP Server 的 httpd.conf 文件，從此文件的下列各行中注釋注釋字符（#）：
#LoadModule status_module, modules/ApacheModuleStatus.dll,#<Location/server-status>#SetHandler server-status#</Location>- 保存更改，然后重新啟動 IBM HTTP Server。
- 在 Web 瀏覽器中，轉至 http://yourhost/server-status。並且，單擊重新裝入以更新狀態。
- （可選）如果瀏覽器支持刷新，那么轉至 http://your_host/server-status?refresh=5 以便每 5 秒鍾刷新一次。
上圖給出了一些其它參數的推薦值。注意Windows平台和其它平台的不同（ThreadsPerChild相當於Maxclients）。關於MinSpareServers,MaxSpareServers, 和StartServers 等的設置，以及MPM使用prefork或worker模塊時的不同，可以閱讀Apache Performance Tuning。
如果你的應用訪問量很大，那么也許你需要優化一下操作系統的tcp/ip相關參數。 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html
並修改“負載均衡”選項和“重試時間間隔”Web 服務器插件屬性設置以提高性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html
Web容器線程池
要點就是：“通常，對於每個服務器 CPU，5 至 10 個線程將會提供最佳吞吐量”（現在的一個cpu可以用核來代替）。比如你的Pc Server有2塊CPU，每塊CPU都是4核，那么你一個Application Server可以設置的最小值和最大值可以分別為40、80。但是一般考慮到能充分利用CPU和Memory，或者為不同的應用啟用不同的application server，一台Pc Server上並不僅有這么一個appserver，而且還有別的進程在占用着CPU，所以默認的10到50（Linux 系統上 25 個）是一個比較合適的值，當然更准確的值需要通過性能測試來確定。
在進行性能測試的時候，如果吞吐率不是很滿意，或者在TPV中看到線程池占用一直是最大值，不要立刻就調大線程池的設置——往往吞吐率會更一步下降。這時候要注意CPU占用率的情況、vmstat的r列值，特別是System狀態占用率的情況，如果接近10%，甚至超過10%，那么可以肯定系統在進程切換上面消耗的資源太多了。下調線程池的大小反而會提升吞吐率，而且會由於吞吐率的提升降低頁面平均響應時間。
這篇文章也許會使你對線程池大小對性能的影響有個感性的認識。
設置的地方大家應該都曉得，單擊服務器 > 應用程序服務器 >server_name > 線程池。
數據庫連接池
連接池的最小值，應該和性能測試時TPV觀察到的jdbc平均大小一樣，最大值根據實際需要設置，每次增長可以設置成大於1，增長一次到位。總之盡量避免連接池頻繁的增長和收縮，減少wait的情況發生。
可以使用 Tivoli Performance Viewer 查找池中最優連接數。如果並發等待者的數目大於 0，但是 CPU 負載未接近 100%，那么考慮增加連接池大小。如果使用百分比值一直低於正常工作負載，那么考慮減少池中的連接數。
Application Server 將在使用該數據源的每個應用程序服務器中創建連接池的單獨實例。例如：
- 如果運行包含三個服務器的集群，這三個服務器都使用myDataSource，並且 myDataSource 的“最大連接數”設置為 10，那么可生成多達 30 個連接（3 個服務器乘以 10 個連接）
這是需要考慮的，別數據庫端的連接大小不夠了。此外，inactive timeout和timeout的時間應該大於收集時間。
總結
這篇文章參考了IBM的inforcenter和developworks，給出了優化WebSphere池大小的一些經驗值，但是真正合適的大小還要參考實際的情況，總之調優是個循序漸進的過程。