WebSphere性能優(yōu)化:你需要多大的池？

發(fā)布: 2009-7-10 16:47 | 作者： hashei | 來源: 本站原創(chuàng) | 查看: 671

What istheCause of the Performance Problem? 或者是How to Improve the Performance?

這是我們?cè)?a onclick="javascript:tagshow(event, '%E7%B3%BB%E7%BB%9F');" href="javascript:;" target="_self">系統(tǒng)開發(fā)、部署過程中都會(huì)面對(duì)的問題，但是卻很難回答。從下面的這幅圖就可以看到，一個(gè)系統(tǒng)的性能瓶頸（bottleneck)，可能在網(wǎng)絡(luò)、防火墻，也能在HttpServer，ApplicationServer，或者是數(shù)據(jù)庫；系統(tǒng)中一個(gè)或者多個(gè)“短板”的存在，就能讓系統(tǒng)無法達(dá)到設(shè)計(jì)時(shí)的目標(biāo)，無法滿足已經(jīng)簽在合同里的SLA……

雖然性能問題牽涉到方方面面，但是本系列關(guān)注點(diǎn)在于中間件這一層。希望能用合理的配置避免諸如OutOfMemory（某些情況下）、數(shù)據(jù)庫連接不夠的發(fā)生，同時(shí)能應(yīng)用一些參數(shù)使系統(tǒng)在不優(yōu)化代碼的情況下有5%到100%的提升。

言歸正傳

池（Pool）是WebSphere中最常涉及的概念之一。從網(wǎng)絡(luò)、Web服務(wù)器、Web 容器、EJB 容器，一直到數(shù)據(jù)源，每一個(gè)環(huán)節(jié)都線程池、連接池的影子。要想恰當(dāng)配置這些池的大小，首先要了解漏斗模型。

通常，WebSphere應(yīng)用中的一個(gè)請(qǐng)求到達(dá)服務(wù)器，到真正開始處理，要經(jīng)過一系列的連接池。廣域網(wǎng)上可能有大量的并發(fā)用戶同時(shí)訪問Web服務(wù)器，Web服務(wù)器上同時(shí)活動(dòng)（Active）的連接可能高達(dá)10000個(gè)。但Web服務(wù)器到應(yīng)用服務(wù)器（Web容器）的連接池大小可能只有200。Web容器到EJB容器的連接池更小，可能是80。然后，經(jīng)過數(shù)據(jù)源（Data source）到數(shù)據(jù)庫的連接最大可能只有25個(gè)。從Web服務(wù)器的連接池到數(shù)據(jù)庫的連接池尺寸逐漸變小，像一個(gè)漏斗（funnel），所以稱為漏斗模型。
摘自《構(gòu)建高性能WebSphere企業(yè)級(jí)應(yīng)用》第二章

IBM000-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

根據(jù)漏斗模型，那么很顯然應(yīng)該選B。

那么實(shí)際生產(chǎn)環(huán)境中就如此依樣畫葫蘆就可以了么？后面的池一定比前面的小么？如果當(dāng)前性能不行，增大池的大小就能提高么？

絕沒有那么簡單。后面的池小于前者，比如數(shù)據(jù)庫連接池小于web線程池，默認(rèn)的假定是：并非每個(gè)JSP和Servlet都需要訪問數(shù)據(jù)庫。如果你的應(yīng)用是數(shù)據(jù)庫密集型的應(yīng)用，基本上每個(gè)JSP和Servlet都需要訪問一次或多次數(shù)據(jù)庫，而且系統(tǒng)中還有一些不經(jīng)過jsp或Servlet的后臺(tái)進(jìn)程。那么數(shù)據(jù)源的連接池就必須大于web容器線程池，否則會(huì)報(bào)無法得到連接的錯(cuò)。

下面按照我的經(jīng)驗(yàn)講述一下每層池大小設(shè)置值

對(duì)于Web服務(wù)器

IBM HTTP Server的優(yōu)化就是對(duì)Apache的優(yōu)化。一般需要調(diào)整httpd.conf中如下參數(shù)：

MaxClients：用來定義Web服務(wù)器可以同時(shí)支持的最大并發(fā)連接數(shù)或并發(fā)用戶數(shù)，默認(rèn)值是600。這個(gè)值需要根據(jù)你所希望的同時(shí)支持的并發(fā)用戶數(shù)來設(shè)置，一般是峰值的120%。當(dāng)然這個(gè)值不能設(shè)的太大，畢竟Apache吃內(nèi)存也是很厲害。我遇到的項(xiàng)目一般是不用調(diào)整的，大家可以根據(jù)實(shí)際負(fù)載動(dòng)態(tài)的調(diào)整MaxClients。

將 IBM HTTP Server 配置為顯示狀態(tài)頁面：
編輯 IBM HTTP Server 的 httpd.conf 文件，從此文件的下列各行中注釋注釋字符（#）：
#LoadModule status_module, modules/ApacheModuleStatus.dll,#<Location/server-status>#SetHandler server-status#</Location>
保存更改，然后重新啟動(dòng) IBM HTTP Server。
在 Web 瀏覽器中，轉(zhuǎn)至 http://yourhost/server-status。并且，單擊重新裝入以更新狀態(tài)。
（可選）如果瀏覽器支持刷新，那么轉(zhuǎn)至 http://your_host/server-status?refresh=5 以便每 5 秒鐘刷新一次。

上圖給出了一些其它參數(shù)的推薦值。注意Windows平臺(tái)和其它平臺(tái)的不同（ThreadsPerChild相當(dāng)于Maxclients）。關(guān)于MinSpareServers,MaxSpareServers, 和StartServers等的設(shè)置，以及MPM使用prefork或worker模塊時(shí)的不同，可以閱讀Apache Performance Tuning。

如果你的應(yīng)用訪問量很大，那么也許你需要優(yōu)化一下操作系統(tǒng)的tcp/ip相關(guān)參數(shù)。http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html

并修改“負(fù)載均衡”選項(xiàng)和“重試時(shí)間間隔”Web 服務(wù)器插件屬性設(shè)置以提高性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html

Web容器線程池

要點(diǎn)就是：“通常，對(duì)于每個(gè)服務(wù)器 CPU，5 至 10 個(gè)線程將會(huì)提供最佳吞吐量”（現(xiàn)在的一個(gè)cpu可以用核來代替）。比如你的Pc Server有2塊CPU，每塊CPU都是4核，那么你一個(gè)Application Server可以設(shè)置的最小值和最大值可以分別為40、80。但是一般考慮到能充分利用CPU和Memory，或者為不同的應(yīng)用啟用不同的application server，一臺(tái)Pc Server上并不僅有這么一個(gè)appserver，而且還有別的進(jìn)程在占用著CPU，所以默認(rèn)的10到50（Linux系統(tǒng)上 25 個(gè)）是一個(gè)比較合適的值，當(dāng)然更準(zhǔn)確的值需要通過性能測(cè)試來確定。

在進(jìn)行性能測(cè)試的時(shí)候，如果吞吐率不是很滿意，或者在TPV中看到線程池占用一直是最大值，不要立刻就調(diào)大線程池的設(shè)置——往往吞吐率會(huì)更一步下降。這時(shí)候要注意CPU占用率的情況、vmstat的r列值，特別是System狀態(tài)占用率的情況，如果接近10%，甚至超過10%，那么可以肯定系統(tǒng)在進(jìn)程切換上面消耗的資源太多了。下調(diào)線程池的大小反而會(huì)提升吞吐率，而且會(huì)由于吞吐率的提升降低頁面平均響應(yīng)時(shí)間。

這篇文章也許會(huì)使你對(duì)線程池大小對(duì)性能的影響有個(gè)感性的認(rèn)識(shí)。

設(shè)置的地方大家應(yīng)該都曉得，單擊服務(wù)器 > 應(yīng)用程序服務(wù)器 >server_name> 線程池。

數(shù)據(jù)庫連接池

連接池的最小值，應(yīng)該和性能測(cè)試時(shí)TPV觀察到的jdbc平均大小一樣，最大值根據(jù)實(shí)際需要設(shè)置，每次增長可以設(shè)置成大于1，增長一次到位。總之盡量避免連接池頻繁的增長和收縮，減少wait的情況發(fā)生。

可以使用 Tivoli Performance Viewer 查找池中最優(yōu)連接數(shù)。如果并發(fā)等待者的數(shù)目大于 0，但是 CPU 負(fù)載未接近 100%，那么考慮增加連接池大小。如果使用百分比值一直低于正常工作負(fù)載，那么考慮減少池中的連接數(shù)。

Application Server 將在使用該數(shù)據(jù)源的每個(gè)應(yīng)用程序服務(wù)器中創(chuàng)建連接池的單獨(dú)實(shí)例。例如：

如果運(yùn)行包含三個(gè)服務(wù)器的集群，這三個(gè)服務(wù)器都使用myDataSource，并且myDataSource的“最大連接數(shù)”設(shè)置為 10，那么可生成多達(dá) 30 個(gè)連接（3 個(gè)服務(wù)器乘以 10 個(gè)連接）