jee性能問題(存儲版)
【正文】 我看來，這些交通燈根本沒用，道理很充分。如果一個請求需要連接到數(shù)據(jù)庫，但是數(shù)據(jù)庫的連接池無法為這個請求創(chuàng)建一個新連接，這個時候請求就會停下來等待連接池完成自己的操作再給她分配一個連接。在此同時，數(shù)據(jù)庫驅(qū)動會從緩存中裝載已經(jīng)準備好的statement ，而不用直接連接到數(shù)據(jù)庫。當你需要一個有狀態(tài)對象時，你需要明確創(chuàng)建這個對象的特定實例，普通的實例是不能滿足的。能在緩存中找到的請求(緩存中有此請求的對象)的百分率稱為hit ratio，相反找不到的請求的百分率稱為miss ratio?！ taless session bean和messagedriven bean池 Stateless session bean 和messagedriven bean 在商業(yè)應(yīng)用方面很重要，不要期望它們會保持自己特有的狀態(tài)信息。為了保險起見，你應(yīng)該親自把它設(shè)置成這個數(shù)。這只是普通的程序回滾，只有當發(fā)生大量的程序回滾才值得我們注意。很多時候人們對發(fā)生的異常很敏感，因此你需要哪些異常對你程序來說才是重要的。原文（英文）。例如，如果你設(shè)置你的程序服務(wù)器通過一個簡單的SQL語句去測試數(shù)據(jù)庫的連接，但數(shù)據(jù)庫對于程序服務(wù)器來說是無法連接的，這個時候任何和這個資源相關(guān)的事情都會發(fā)生資源回滾。如果一個16歲的提交了信息，那么程序就會拋出一個錯誤，打開一個網(wǎng)頁告訴他，他年齡還不能參與到這個信息的調(diào)查。Stateless bean池的大小應(yīng)該和可執(zhí)行線程池的大小一般大，因為一個線程同時只能使用一個對象，再多了就造成浪費的?！ ∫坏┠阌X得你的緩存太小，就去嘗試著增大大小，并測試增加的性能。特別是，當一個請求去一個已經(jīng)滿了的緩存區(qū)域去請求一個對象的時候，下面的步驟就會執(zhí)行，這些步驟會在圖11中顯示: 1. 程序請求一個對象 2. 緩存檢測這個對象是否已經(jīng)存在于緩存中 3. 緩存決定把一個對象開除出緩存(一般采用的算法是遺棄最近使用次數(shù)最少的對象) 4. 把這個對象扔出緩存(稱為passivated) 5. 把從數(shù)據(jù)庫中裝載這個新對象并放入到緩存(稱為activated) 6. 把指向這個對象的引用返回給程序 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ù)的請求都需要執(zhí)行這些步驟的話，那你采用緩存技術(shù)就不是好的選擇了!如果這些處理步驟頻繁發(fā)生的話，你就需要重新推敲下你的緩存了。 通過跟蹤性能，確定出你程序所執(zhí)行的不重復(fù)的statement 的數(shù)量，并從這些statement 中找出哪些條是頻繁執(zhí)行的。在返回的時候，程序重新描述這些結(jié)果并描述出這些被請求的信息?！ DBC連接池 很多JAVA EE 程序連接到一個后臺數(shù)據(jù)源，大多數(shù)是通過JDBC(JAVA DATABASE CONNECTIVITY)將程序和后臺連接起來。讓CPU保持持續(xù)的高使用率，同時性能不降低，新請求到來的時候放入到隊列中，這是最理想的程序。因此，我建議你為一個CPU分配50到75個左右的線程。由于這些值非常依賴程序的行為，他們只告訴你大普通情況下正確的大小，但是他們給了你一個范圍內(nèi)的值，這對用戶很有利的。程序把接受到的請求放到待執(zhí)行隊列中，然后將這個請求從隊列移動到線程中被程序處理。如果你想讓他能夠裝載所有的類的時候，就會導(dǎo)致一個典型的結(jié)構(gòu)錯誤。于是JVM就再重新檢測持久空間，看它是否滿，然后再次執(zhí)行程序，一遍的一遍重復(fù)。堆僅僅存儲類的實例，但JVM在堆中創(chuàng)建類實例之前，它必須把字節(jié)流文件(.class文件)裝載到程序內(nèi)存中。如果程序服務(wù)器發(fā)生內(nèi)存溢出，判斷是內(nèi)存泄漏還是內(nèi)存缺乏的最好的方法就是:停止所有向這個服務(wù)器所發(fā)的請求的對象，等待會話超時，看內(nèi)存時候會被釋放出來。如果在INIT()方法中裝載配置信息，將他存儲于類變量中，那么當需要維護的時候就可以隨時讀出這些信息，這樣所有的對象就用相同的配置。ServletContext的有效范圍是整個程序，因此你可以利用Servlet中的ServletContext或者JSP應(yīng)用程序?qū)ο笤谒械腟ervlet和JSP之間讓在這個程序中的所有用戶共享數(shù)據(jù)?！ TTP是無狀態(tài)的，這意味著客戶向服務(wù)器發(fā)送一個請求，服務(wù)器回應(yīng)這個請求，這個傳遞就完成了，就是會話結(jié)束了。 為了判斷是否過早的對堆進行分析，持續(xù)2個小時對跟蹤到的分析快照進行分析，看堆的使用率是上升還是下降。這些工具利用字節(jié)流工具跟蹤對象的創(chuàng)建和銷毀的數(shù)量，他們可以報告特定類中的對象的數(shù)量狀態(tài)，例如把Collections類作為特定的請求。 5. 再次拍照，來捕獲使用方案運行之后堆中所有對象的狀態(tài)。下面的這個設(shè)置能夠給你提供足夠的分析數(shù)據(jù): –verbose:gc –xloggc: –XX:+PrintGCDetails –XX:+PrintGCTimeStamps 明確發(fā)現(xiàn)在整個堆中存在有潛在可能泄漏內(nèi)存的情況，用老一代增長的速率才比較有說服力?！ D5顯示了那些潛在可能造成泄漏的對象:主收集器收集后遺留下來占據(jù)空間的對象會越來越多。處理的順序十分重要:垃圾收集器首先掃描EDEN和生存者空間，這就保證了占據(jù)空間的對象有足夠的機會證明自己是有效的?！ UN JVM會劃分為: 1 年輕的一代(Young generation)，包括EDEN和2個幸存者空間(出發(fā)地和目的地the From space and the To space) 2 老一代(Old generation) 3 永久的一代(Permanent generation)圖1 解釋了SUN 堆的家族和空間的詳細分類對象在EDEN出生就是被創(chuàng)建，當EDEN滿了的時候，垃圾收集器就把所有在EDEN中的對象掃描一次，把所有有效的對象拷貝到第一個幸存者空間，同時把無效的對象所占用的空間釋放。這塊內(nèi)存就被占用了，堆中也就少了塊可用的空間。希望這篇文章能成為你JAVAEE的故障檢測手冊。JEE性能問題這篇文章，是PRO JAVA EE 5 Performance Management and Optimization 的一個章節(jié)，作者Steven Haines分享了他在調(diào)優(yōu)企業(yè)級JAVA應(yīng)用時所遇到的常見問題。在這一節(jié)，我分享我在這個領(lǐng)域遇過的常見問題和他們的癥狀。當一個對象不再被使用時，但是依然有一個或多個對象引用這個對象，因此垃圾收集器就不會釋放它所占據(jù)的內(nèi)存?！ UN JVM的內(nèi)存管理方式 SUN的JVM是類似人類家族，也就是在一個地方創(chuàng)建對象，在它長期占
法律信息相關(guān)推薦
鄂ICP備17016276號-1