Ben Gidley進行了一個關於Tapestry5.1.0.5的性能評測。最後，他得出的結論是：
1、Tapestry5的速度是比較快的。即使在一定的壓力下Tapestry的反應時間也相當短。Tapestry並不總是最快的解決方案，但它對於我（譯注：Gidley）已經足夠快了。
2、Tapestry5沒有內存洩漏。我以前曾經聽說過Tapestry會占用大量的內存，實際上，正好相反。它使用的內存比Struts/JSP還要少。內存使用曲線相當的平坦。
3、Tapestry5在表單應用中比struts要快。Tapestry在應用變得非常復雜的時候有一定的優勢。這可能利益於其模塊池技術。
4、Tapestry5不輕易崩潰，即使崩潰，也會恢復。Tapestry在極大壓力的情況下確實會相應變慢，但是它會暫停或者遇到瓶頸（譯注：我懷疑是作者這裡有筆誤，從語氣和上下文來看，感覺應該不是暫停和沒有瓶頸），這的確是一個好事情。另外在壓力減輕之後，Tapestry能夠自動恢復。
5、更多的CPU並一定會提升性能。在一系列的測試中，性能與CPU的數量並不是線性增長。２個CPU確實比一個CPU的性能翻倍了，但是４個CPU並不比２個CPU的性能翻倍。因此，建議在多個雙核CPU的虛擬機上運行，而不是少數的４核CPU上運行。
6、６４位比３２位要快。這一點很讓我驚奇。不管在Solaris還是Linux上，運行在６４位JVM中要比在３２位JVM要快。
7、Linux要比Open Solaris X86要快。這一點同樣讓我驚奇。我本來以為性能應該是相似的。
最終的結論是：Tapestry即使是對於一個大並發量的Web應用來說也已經足夠快了。如果你的應用有性能問題的話，那麼問題應該出在你自己本身的代碼上。
Taptestry５和Struts相比，我認為差別應該是在反射的使用上（包括在java.bean.Introspector中大量的synchronization）。因此在Struts將查詢參數的名稱映射成JavaBean屬性的時候，會比較耗時。而Tapestry５是不使用反射的，Tapestry在查詢參數和JavaBean的屬性之間使用一種“預編程”向量組件，也許這就是兩者（Tapestry和Struts）的差別。當然，這只是猜想，如果要證實的話，是需要花費很多時間的。我認為OGNL的教訓不是說反射很慢，而是在於一個關鍵代碼上的序列存取對於性能的影響是相當大的。
最後一個小提示：我覺得在Tapestry5應用中如果把BeanModel從BeanModelSource中只提取一次，然後給Grid，BeanEditForm等等提供一個可以存取的方法，將會獲得相當的性能提升。這樣就不是需要每次都重建BeanModel，將減少操作的消耗。
