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