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，将减少操作的消耗。
【编辑推荐】
