問題終於找到，簡單的說是因為java 序列化的效率低下，而ejb調用之間又大量使用序列化，因此造成極大的性能消耗，而且也影響到響應時間。仔細分析了一下項目情況，呵呵，情況非常嚴重，系統架構是按照三層來設計的，每個層都是ejb，調下一層都是通過遠程接口，而且層之間可能還多個ejb的調用。
（說句題外話，這種設計個人感覺非常，恩，不理解，性能殺手，而且ejb配置極其復雜，當然或者ejb本來就是如此，ebj和weblogic對我來說是很陌生很高深的東西，目前還沒有深入掌握。）
很自然的會想到ejb2.0中的配置項enable-call-by-reference，如果能夠開啟就可以避免遠程接口調用中的序列化。檢查配置文件發現幾乎能設置enable-call-by-reference的地方都設置為true了，奇
怪，再檢查部署方式時發現，恩，暈倒，被部署到不同的ear包中了。
不同的ear包，enable-call-by-reference就算設置位true也開啟不了吧？
接下來的改進方式，很自然就想到，如果能打包到同一個ear中，就可以在不改動代碼，不改動部署文件的情況下解決這個問題，似乎是一個不錯的好想法。
謹慎起見，同時為了拿到足夠的證據來說法上層，先做個試驗先。
模擬公司的項目結構，單獨寫了一個project，1個servlet負責接受外界請求，3個SLSB模擬三層工作，ejb直接只提供遠程接口，然後打包到同一個ear包進行測試。當然enable-call-by-reference設置為true
和false來進行對比測試。
為了突出這個差異，ejb中都不進行任何操作，也不sleep。這樣消耗就主要體現在java 序列化的消耗上，而且為了模擬真實情況，參數設置的比較大，裡面放了1000個instance。
使用loadrunner，開啟100個測試線程，通過http訪問servlet，測試時間一分鐘，看能執行多少次請求，測試結果如下：
enable-call-by-reference = false : 558
enable-call-by-reference = true : 21163
由於這個結果的差異性實在是太大了，因此沒有必要進行多次測試，近40倍的差異完全可以反應問題了，當時實際項目中應該遠沒有這麼誇張。
總結一下：
1. java serialize 非常慢
2. enable-call-by-reference可以有效避免這個開銷
因此，能enable-call-by-reference就盡量enable-call-by-reference。
ps:順便將這個測試的eclipse project也分享出來吧，請在這裡下載
http://www.fs2you.com/files/045b367d-5d23-11dd-a2ed-0014221b798a/
