轉自：http://blog.sina.com.cn/s/blog_67219a720101bh49.html
留以後學習使用。
應用服務器通俗點就是後臺程序 ，但是也不只是後臺程序，也可能是其他的程序，在這裏我主要講後臺程序的調優。也是建立在weblogic和oracle數據庫之上的， 如果不會weblogic，請大家去網上看看，我個人認爲weblogic簡直是神器。
1 jvm調優
任何java程序都是建立在jvm的基礎上的，但是做項目的時候很少用jvm調優，我記得上次我給出了40W併發處理方案裏面談到了jvm的調優，在這裏就詳細的說下。
1.1 垃圾收集和堆大小
垃圾收集(GC)是指JVM釋放Java堆中不再使用的對象所佔用的內存的過程,而Java堆(Heap)是指Java應用程序對象生存的空間【所以上篇優化的時候少創建一寫對象】。堆大小決定了GC的頻度和時間。堆越大,GC頻度低,速度慢。堆越小,GC頻度高,速度快。所以GC和堆大小是一組矛盾。爲了獲取理想的Heap堆大小,需要使用-verbosegc參數(Sun jdk: -Xloggc:)以打開詳細的GC輸出。分析GC的頻度和時間,結合應用最大負載所需內存情況,得出堆的大小。
通常情況下,我們建議使用可用內存(除操作系統和其他應用程序佔用之外的內存)70-80%,爲避免堆大小調整引起的開銷,設置內存堆的最小值等於最大值即:- Xms=-Xmx。而爲了防止內存溢出,建議在生產環境堆大小至少爲256M(Platform至少512M),實際環境中512M~1G左右性能最佳, 2G以上是不可取的,在調整內存時可能需要調整核心參數進程的允許最大內存數。對於sun和hp的jvm,永久域太小(默認4M)也可能造成內存溢出,應增加參-XX:MaxPermSize=128m。建議設置臨時域-Xmn的大小爲-Xmx的1/4~1/3, SurvivorRatio爲8。
爲了獲得更好的性能,建議在啓動文件設置WebLogic爲產品模式,此時sun和hp jvm JIT引擎爲-server,默認情況下打開JIT編譯模式對性能也有幫助。調整Chunk Size和Chunk Pool Size也可能對系統的吞吐量有提高。此外還需關閉顯示GC: -XX:+DisableExplicitGC。
當然在Intel平臺上使用jRockit（使用參數-jrockit）無疑大大提高WebLogic性能。
1.1.2 jRockit調優
jRockit支持四種垃圾收集器：分代複製收集器、單空間併發收集器、分代併發收集器和並行收集器。默認狀態下，JRockit使用分代併發收集器。要改變收集器，可使用-Xgc:,對應四個收集器分其他爲gencopy, singlecom, gencon以及parallel。爲得到更好的響應性能，應該使用併發垃圾回收器：-Xgc:gencon，可使用-Xms和-Xmx設置堆棧的初始大小和最大值,要設置護理域-Xns爲-Xmx的10%。而如果要得到更好的性能，應該選用並行垃圾回收器:-Xgc: parallel，由於並行垃圾回收器不使用nursery，不必設置-Xns。
如果你的線程大於100或者在linux平臺下，可以嘗試使用瘦線程模式：-Xthinthread,同時關閉Native IO:-Xallocationtype:global。
jRockit 還提供了強大的圖形化監控工具Jrockit Management Console。欲詳細瞭解JRockit可訪問：http://edocs.bea.com/wljrockit/docs81/index.html。
2 Server調優
WebLogic Server的核心組件由監聽線程,套接字複用器和可執行線程的執行隊列組成。當服務器由監聽線程接收到連接請求後,將對它的連接控制權交給等待接收請求的套接字複用器。然後套接字複用器讀取離開套接字的請求,並將此請求及相關安全信息或事務處理環境一起置入適當的執行隊列中(一般爲默認的執行隊列)。當有一個請求出現在執行隊列中時，就會有一個空閒的執行線程從該隊列中取走發來的該請求，並返回應答，然後等待下一次請求。因此要提高WebLogic的性能,就必須從調整核心組件性能出發。
1.2.1 儘量使用本地I/O庫
WebLogic Server有兩套套接字複用器：Java版和本地庫。採用小型本地庫更有效,儘量激活Enable Native IO(默認),此時UNIX默認使用CPUs+1個線程,Window下爲雙倍CPU。如果系統不能加載本地庫,將會拋出 java.lang.UnsatisfiedLinkException,此時只能使用Java套接字複用器,可以調整socket readers 百分比,默認爲33%。該參數可以在Console Server Tuning Configuration配置欄裏設置。
1.2.2 調整默認執行線程數
理想的默認執行線程數是由多方面的因素決定的,比如機器CPU性能、總線體系架構、I/O、操作系統的進程調度機制、JVM的線程調度機制。 WebLogic生產環境下默認的線程爲25個,隨着CPU個數的增加,WebLogic可以近乎線性地提高線程數。線程數越多，花費在線程切換的時間也就越多,線程數越小,CPU可能無法得到充分利用。爲獲取一個理想的線程數,需要經過反覆的測試。在測試中,可以以25*CPUs爲基準進行調整。當空閒線程較少,CPU利用率比較低時,可以適當增加線程數的大小(每五個遞增)。對於PC Server 和Window 2000，則最好每個CPU小於50個線程, 以CPU利用率爲90%左右爲佳。由於目前WebLogic執行線程沒有縮小線程數的功能,所以應將參數Threads Increase設置爲0,同時不應改變優先級的大小。
2.2.3 調整連接參數
WebLogic Server用Accept Backlog參數規定服務器向操作系統請求的隊列大小，默認值爲50。當系統重載負荷時,這個值可能過小,日誌中報Connection Refused,導致有效連接請求遭到拒絕,此時可以提高Accept Backlog 25%直到連接拒絕錯誤消失。對於Portal類型的應用,默認值往往是不夠的。Login Timeout和SSL Login Timeout參數表示普通連接和SSL連接的超時時間,如果客戶連接被服務器中斷或者SSL容量大,可以嘗試增加該值。這些參數可以在Console Server Tuning Configration配置欄裏找到。
3 jdbc的調優
jdbc的調優，在項目的是很重要的，特別是在大數據的時候尤爲重要，JDBC Connection Pool的調優受制於WebLogic Server線程數的設置和數據庫進程數,遊標【注意resultRet就是通過遊標取出的，所以使用的時候要注意特別是大數據的時候】的大小。通常我們在一個線程中使用一個連接,所以連接數並不是越多越好,爲避免兩邊的資源消耗，建議設置連接池的最大值等於或者略小於線程數。同時爲了減少新建連接的開銷,將最小值和最大值設爲一致。
增加Statement Cache Size對於大量使用PreparedStatement對象的應用程序很有幫助,WebLogic能夠爲每一個連接緩存這些對象,此值默認爲10。在保證數據庫遊標大小足夠的前提下,可以根據需要提高Statement Cache Size。比如當你設置連接數爲25,Cache Size爲10時,數據庫可能需要打開25*10=250個遊標。不幸的是,當遇到與PreparedStatement Cache有關的應用程序錯誤時,你需要將Cache Size設置爲0。
儘管JDBC Connection Pool提供了很多高級參數,在開發模式下比較有用,但大部分在生產環境下不需調整。這裏建議最好不要設置測試表, 同時Test Reserved Connections和Test Released Connections也無需勾上。當然如果你的數據庫不穩定,時斷時續,你就可能需要上述的參數打開。
最後提一下驅動程序類型的選擇,以Oracle爲例, Oracle提供thin驅動和oci驅動,從性能上來講,oci驅動強於thin驅動,特別是大數據量的操作。但在簡單的數據庫操作中,性能相差不大, 隨着thin驅動的不斷改進,這一弱勢將得到彌補。而thin驅動的移植性明顯強於oci驅動。所以在通常情況下建議使用thin驅動。而最新驅動器由於 WebLogic server/bin目錄下的類包可能不是最新的,請以Oracle網站爲準: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html