Tapestry5的性能改進(jìn)淺析
Ben Gidley進(jìn)行了一個(gè)關(guān)于Tapestry5.1.0.5的性能評(píng)測(cè)。最后，他得出的結(jié)論是：
1、Tapestry5的速度是比較快的。即使在一定的壓力下Tapestry的反應(yīng)時(shí)間也相當(dāng)短。Tapestry并不總是最快的解決方案，但它對(duì)于我（譯注：Gidley）已經(jīng)足夠快了。
2、Tapestry5沒(méi)有內(nèi)存泄漏。我以前曾經(jīng)聽(tīng)說(shuō)過(guò)Tapestry會(huì)占用大量的內(nèi)存，實(shí)際上，正好相反。它使用的內(nèi)存比Struts/Jsp還要少。內(nèi)存使用曲線相當(dāng)?shù)钠教埂?/P>
3、Tapestry5在表單應(yīng)用中比struts要快。Tapestry在應(yīng)用變得非常復(fù)雜的時(shí)候有一定的優(yōu)勢(shì)。這可能利益于其模塊池技術(shù)。
4、Tapestry5不輕易崩潰，即使崩潰，也會(huì)恢復(fù)。Tapestry在極大壓力的情況下確實(shí)會(huì)相應(yīng)變慢，但是它會(huì)暫停或者遇到瓶頸（譯注：我懷疑是作者這里有筆誤，從語(yǔ)氣和上下文來(lái)看，感覺(jué)應(yīng)該不是暫停和沒(méi)有瓶頸），這的確是一個(gè)好事情。另外在壓力減輕之后，Tapestry能夠自動(dòng)恢復(fù)。
5、更多的CPU并一定會(huì)提升性能。在一系列的測(cè)試中，性能與CPU的數(shù)量并不是線性增長(zhǎng)。２個(gè)CPU確實(shí)比一個(gè)CPU的性能翻倍了，但是４個(gè)CPU并不比２個(gè)CPU的性能翻倍。因此，建議在多個(gè)雙核CPU的虛擬機(jī)上運(yùn)行，而不是少數(shù)的４核CPU上運(yùn)行。
6、６４位比３２位要快。這一點(diǎn)很讓我驚奇。不管在Solaris還是Linux上，運(yùn)行在６４位JVM中要比在３２位JVM要快。
7、Linux要比Open Solaris X86要快。這一點(diǎn)同樣讓我驚奇。我本來(lái)以為性能應(yīng)該是相似的。
最終的結(jié)論是：Tapestry即使是對(duì)于一個(gè)大并發(fā)量的Web應(yīng)用來(lái)說(shuō)也已經(jīng)足夠快了。如果你的應(yīng)用有性能問(wèn)題的話，那么問(wèn)題應(yīng)該出在你自己本身的代碼上。
Taptestry５和Struts相比，我認(rèn)為差別應(yīng)該是在反射的使用上（包括在java.bean.Introspector中大量的synchronization）。因此在Struts將查詢參數(shù)的名稱映射成JavaBean屬性的時(shí)候，會(huì)比較耗時(shí)。而Tapestry５是不使用反射的，Tapestry在查詢參數(shù)和JavaBean的屬性之間使用一種“預(yù)編程”向量組件，也許這就是兩者（Tapestry和Struts）的差別。當(dāng)然，這只是猜想，如果要證實(shí)的話，是需要花費(fèi)很多時(shí)間的。我認(rèn)為OGNL的教訓(xùn)不是說(shuō)反射很慢，而是在于一個(gè)關(guān)鍵代碼上的序列存取對(duì)于性能的影響是相當(dāng)大的。
最后一個(gè)小提示：我覺(jué)得在Tapestry5應(yīng)用中如果把BeanModel從BeanModelSource中只提取一次，然后給Grid，BeanEditForm等等提供一個(gè)可以存取的方法，將會(huì)獲得相當(dāng)?shù)男阅芴嵘＿@樣就不是需要每次都重建BeanModel，將減少操作的消耗。
【編輯推薦】
