有一個J2EE項目，碰到一些性能問題?？蛻粲肔oadRunner測試，十個用戶并發測試登錄，就導致系統崩潰。經過檢查，發現是數據池設置的太小，在IBM  WPS里面設置的數據池缺省是1-10，結果當用5個并發測試的時候，就總是有5個進程在等待數據連接。這樣，系統自然通不過測試了。后來把數據池改大了，測試通過，而且速度飛快。

J2EE的性能問題，是Java誕生以來就一直存在的問題，盡管這些年間已經有了非常大的改進，但畢竟還是不如C等代碼生成的程序。但我們在碰到J2EE程序性能的時候，卻不能總把問題歸咎于Java的問題。事實上，在很大程度上，J2EE碰到的性能問題，都是環境方面的配置問題。

簡單列舉一下J2EE可能碰到的性能方面的一些可能原因：
1、JVM內存分配的問題。JVM如果沒有單獨設置，缺省使用的內存是比較有效的，好像是32M。這樣的內存，對于大并發訪問是遠遠不夠的，需要根據服務器的內存情況進行優化，這時候常常會拋內存溢出的錯誤。但也不能無限大，JVM最多只能使用2G的內存。比如，通常可以設置為 -Xms512m -Xmx1024m。
2、WEB服務器的并發服務線程數。通常的WEB容器都有這樣一個限制，比如Tomcat缺省是75.這時候，如果使用LoadRunner等進行100用戶并發測試，則肯定有不少請求會等待，而不是完全執行。WebLogic的缺省設置好像更小，我記得反正不到30.如果在實際使用中，發現這個并發線程數是瓶頸，則可以調得更大一些。
3、數據池的大小，這正好是朋友碰到的問題。通常情況下，數據池的大小，應該略大于WEB服務器的并發服務線程數。我們至少要保證每個WEB進程都能獲取到相應的數據連接。如果每個WEB進程，可能需要多個數據連接，這時候數據池也應該相應調整的更大。
4、數據表的索引問題。對普通程序員，碰到性能問題的時候，很難想到表索引的問題。特別是針對大數據量的數據表，有沒有合理索引的情況，查詢的效率，往往是幾十上百倍。建索引之前一個小時才能完成的任務，如果有合理的索引，可能1分鐘不到就能搞定。索引的最簡單的設置規則，就是把Where、Order子句中的所有字段都建上索引。

從以上這幾個方面，往往能解決大部分的性能問題。
再來說說碰到性能問題的時候大概的思路。原則只有一個，就是“定位問題所在”。
1、查看服務器日志，日志里面的很多的有用信息，能從中初步發現問題所在。
2、結合日志，查看相應的設置，并對服務器進行監控。然后對參數進行必要的調整，繼續測試。
3、如果定位到是數據庫上是瓶頸，就要檢查相應的數據表的索引設置。有些數據庫提供SQL語句的監控和性能分析，可以分析出一些有用的結論。
以上只是一些初步的指導。如果一些初步的設置解決不了問題，則需要進一步細化了。
比如說索引的問題，簡單的規則是給所有Where子句后面的字段添加索引。但這條規則太簡單，某些情況下并不適用，這時候就要根據數據表的數據量、數據的差異、SQL語句等進行仔細調整。這就需要更多的經驗、更仔細的調試才能得到更好的效果。
如果以上都解決不了問題，這時候就要考慮代碼上是不是需要優化了。