【正文】 的行為，他們只告訴你大普通情況下正確的大小，但是他們給了你一個(gè)范圍內(nèi)的值，這對(duì)用戶很有利的。因此，為第一個(gè)程序配置的池大小是100就有點(diǎn)太小了，因?yàn)槌绦蚰軌蛲瑫r(shí)處理200個(gè)。因此，我建議你為一個(gè)CPU分配50到75個(gè)左右的線程。　　連接池過(guò)大的最主要的跡象就是CPU的使用率一直很高。讓CPU保持持續(xù)的高使用率，同時(shí)性能不降低，新請(qǐng)求到來(lái)的時(shí)候放入到隊(duì)列中，這是最理想的程序。如果所有的車輛都同時(shí)涌向公里，我們就動(dòng)彈不得，但是只要減緩涌向高速公路車輛的速度，交通遲早會(huì)暢通?！　DBC連接池　　很多JAVA EE 程序連接到一個(gè)后臺(tái)數(shù)據(jù)源，大多數(shù)是通過(guò)JDBC(JAVA DATABASE CONNECTIVITY)將程序和后臺(tái)連接起來(lái)。我們調(diào)試的目的就是盡量減少請(qǐng)求的等待時(shí)間和飽和的資源之間之間的沖突，讓一個(gè)請(qǐng)求在數(shù)據(jù)庫(kù)外等待要比強(qiáng)迫數(shù)據(jù)庫(kù)好的多。在返回的時(shí)候，程序重新描述這些結(jié)果并描述出這些被請(qǐng)求的信息。prepared statement 緩存區(qū)設(shè)置不恰當(dāng)最主要的癥狀就是花費(fèi)大量的時(shí)間去連接相同的statement?！　⊥ㄟ^(guò)跟蹤性能，確定出你程序所執(zhí)行的不重復(fù)的statement 的數(shù)量，并從這些statement 中找出哪些條是頻繁執(zhí)行的。也就是，售貨員被放入池中共享，因?yàn)槟阒恍枰鞘圬泦T就可以，而不是一個(gè)叫做史締夫的這個(gè)售貨員。特別是，當(dāng)一個(gè)請(qǐng)求去一個(gè)已經(jīng)滿了的緩存區(qū)域去請(qǐng)求一個(gè)對(duì)象的時(shí)候，下面的步驟就會(huì)執(zhí)行，這些步驟會(huì)在圖11中顯示:　　1. 程序請(qǐng)求一個(gè)對(duì)象 　　2. 緩存檢測(cè)這個(gè)對(duì)象是否已經(jīng)存在于緩存中 　　3. 緩存決定把一個(gè)對(duì)象開(kāi)除出緩存(一般采用的算法是遺棄最近使用次數(shù)最少的對(duì)象) 　　4. 把這個(gè)對(duì)象扔出緩存(稱為passivated) 　　5. 把從數(shù)據(jù)庫(kù)中裝載這個(gè)新對(duì)象并放入到緩存(稱為activated) 　　6. 把指向這個(gè)對(duì)象的引用返回給程序　Figure 11. Because the requested object is not in the cache, an object must be selected for removal from the cache and removed from it.　　如果多數(shù)的請(qǐng)求都需要執(zhí)行這些步驟的話，那你采用緩存技術(shù)就不是好的選擇了!如果這些處理步驟頻繁發(fā)生的話，你就需要重新推敲下你的緩存了。初始化以后，你應(yīng)該跟蹤passivation的數(shù)量并把它和與向緩存請(qǐng)求對(duì)象的請(qǐng)求的總量相比較，因?yàn)閜assivations只會(huì)發(fā)生在緩存被初始化以后?！　∫坏┠阌X(jué)得你的緩存太小，就去嘗試著增大大小，并測(cè)試增加的性能。如果你的程序過(guò)了一會(huì)又需要這個(gè)一摸一樣的BEAN，就從池中再得到一個(gè)實(shí)例，但不能保證你得到的就是上一個(gè)實(shí)例。Stateless bean池的大小應(yīng)該和可執(zhí)行線程池的大小一般大，因?yàn)橐粋€(gè)線程同時(shí)只能使用一個(gè)對(duì)象，再多了就造成浪費(fèi)的。通過(guò)JAVAEE 5 EJB(Enterprise javaBeans)的注釋，你可以控制事務(wù)中方法的使用。如果一個(gè)16歲的提交了信息，那么程序就會(huì)拋出一個(gè)錯(cuò)誤，打開(kāi)一個(gè)網(wǎng)頁(yè)告訴他，他年齡還不能參與到這個(gè)信息的調(diào)查。有三種情形的非程序回滾:　　1. 系統(tǒng)回滾 　　2. 超時(shí)回滾 　　3. 資源回滾　　系統(tǒng)回滾意味著程序服務(wù)器中的一些東西非常的糟糕，恢復(fù)的幾率很渺茫。例如，如果你設(shè)置你的程序服務(wù)器通過(guò)一個(gè)簡(jiǎn)單的SQL語(yǔ)句去測(cè)試數(shù)據(jù)庫(kù)的連接，但數(shù)據(jù)庫(kù)對(duì)于程序服務(wù)器來(lái)說(shuō)是無(wú)法連接的，這個(gè)時(shí)候任何和這個(gè)資源相關(guān)的事情都會(huì)發(fā)生資源回滾。這篇文章的注意力并不是放在程序代碼的問(wèn)題上，因?yàn)榘炎⒁饬Ψ旁谝驗(yàn)榄h(huán)境的問(wèn)題而導(dǎo)致的低性能的問(wèn)題上:　　 　　 　　 　　 　　 　　 　　　　為了有效的診斷性能的問(wèn)題，你應(yīng)該了解什么問(wèn)題會(huì)導(dǎo)致什么樣的癥狀。原文（英文）?！　?wèn)題的根源依賴于很多要素，但是一些指示器可以增加一些你處理問(wèn)題時(shí)候的一些信心，依靠他們可以完全排除一些其他的原因。很多時(shí)候人們對(duì)發(fā)生的異常很敏感，因此你需要哪些異常對(duì)你程序來(lái)說(shuō)才是重要的。除非你把超時(shí)設(shè)置的很短才會(huì)出現(xiàn)這種錯(cuò)誤。這只是普通的程序回滾，只有當(dāng)發(fā)生大量的程序回滾才值得我們注意。回滾會(huì)是下面2種情況:　　1. 程序造成的回滾(程序回滾) 　　2. 非程序造成的回滾(非程序回滾)　　通常，程序回滾是因?yàn)樯虡I(yè)的規(guī)定。為了保險(xiǎn)起見(jiàn)，你應(yīng)該親自把它設(shè)置成這個(gè)數(shù)。如果你無(wú)法從池中得到想要的BEAN，請(qǐng)求就會(huì)等待，一直到這個(gè)BEAN被放入到池中。　　Staless session bean和messagedriven bean池　　Stateless session bean 和messagedriven bean 在商業(yè)應(yīng)用方面很重要，不要期望它們會(huì)保持自己特有的狀態(tài)信息。如果miss ratio超過(guò)25%，那么緩存可能是太小了。能在緩存中找到的請(qǐng)求(緩存中有此請(qǐng)求的對(duì)象)的百分率稱為hit ratio，相反找不到的請(qǐng)求的百分率稱為miss ratio。這個(gè)時(shí)候，孩子就需要被緩存。當(dāng)你需要一個(gè)有狀態(tài)對(duì)象時(shí)，你需要明確創(chuàng)建這個(gè)對(duì)象的特定實(shí)例，普通的實(shí)例是不能滿足的。　　事情變的稍微復(fù)雜了點(diǎn)，緩存prepared statement 是每個(gè)statement的基礎(chǔ)，就是說(shuō)在一個(gè)statement連接之前都應(yīng)當(dāng)緩存起來(lái)。在此同時(shí)，數(shù)據(jù)庫(kù)驅(qū)動(dòng)會(huì)從緩存中裝載已經(jīng)準(zhǔn)備好的statement ，而不用直接連接到數(shù)據(jù)庫(kù)。當(dāng)你的程序在數(shù)據(jù)庫(kù)中運(yùn)行SQL statement 的時(shí)候三下面3個(gè)步驟進(jìn)行:　　 　　 　　　　在準(zhǔn)備階段，數(shù)據(jù)庫(kù)驅(qū)動(dòng)器讓數(shù)據(jù)庫(kù)完成隊(duì)列中的執(zhí)行計(jì)劃。如果一個(gè)請(qǐng)求需要連接到數(shù)據(jù)庫(kù)，但是數(shù)據(jù)庫(kù)的連接池?zé)o法為這個(gè)請(qǐng)求創(chuàng)建一個(gè)新連接，這個(gè)時(shí)候請(qǐng)求就會(huì)停下來(lái)等待連接池完成自己的操作再給她分配一個(gè)連接。設(shè)置一個(gè)飽和的池，然后逐步減少連接池大小，一直到CPU占用率為75%到85%之間，同時(shí)用戶負(fù)載正常。在我看來(lái)，這些交通燈根本沒(méi)用，道理很充分?！　∵@個(gè)情況發(fā)生的時(shí)候，請(qǐng)求會(huì)被放在隊(duì)列中不被處理，但是不會(huì)始終如此，因?yàn)檎?qǐng)求占用CPU的情況和程序占用的情況造成的后果不同?！　【€程池太大　　除了線程池?cái)?shù)量太小之外的情況外，環(huán)境也可能把線程數(shù)量配置的過(guò)大?！　〉牵芏喑绦虿](méi)有在這種情況下動(dòng)態(tài)的去調(diào)整的功能。第一個(gè)程序?qū)φ?qǐng)求的回應(yīng)會(huì)很塊，且不怎么占據(jù)CPU。當(dāng)你觀測(cè)吞吐量的時(shí)候，如果你發(fā)現(xiàn)吞吐量降低了，你就應(yīng)該把池的大小下調(diào)一個(gè)幅度，一直到找到讓它保持最大吞吐量的大小為止。Figure 8. 服務(wù)器處理請(qǐng)求的次序結(jié)構(gòu)線程池太小　　每當(dāng)我碰到有人抱怨裝載速度的性能隨著裝載的數(shù)量的增加變的越來(lái)越糟糕的時(shí)候，我會(huì)首先檢查線程池。如果