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