Ben Gidley 對 Tapestry 5.1.0.5 進行系統效能評測，涵蓋回應時間、記憶體洩漏、表單處理、高壓行為、CPU 縮放、JVM 位元數、作業系統差異七大維度。
| # | 發現 | 技術解讀 |
|---|---|---|
| 1 | 速度夠快：壓力下回應時間極短 | 雖非絕對最快，但滿足絕多數業務場景。核心優勢在於元件池化與編譯優化。 |
| 2 | 無記憶體洩漏：記憶體曲線平坦，佔用低於 Struts/JSP | 反直覺結果：Tapestry 5 記憶體效率優於傳統架構，得益於無反射、靜態結構分析。 |
| 3 | 表單處理超越 Struts：複雜表單場景優勢明顯 | 歸功於「預編程向量元件」：查詢參數到 JavaBean 屬性的映射無反射開銷。 |
| 4 | 高壓不崩潰，自動恢復：遇到瓶頸緩降而非崩潰，壓力釋放自動回升 | 具備背壓與熔斷機制，保護系統穩定性，適合生產環境。 |
| 5 | CPU 非線性縮放：2 CPU ≈ 2× 效能，4 CPU < 2× 雙核效能 | 建議：部署於多個雙核虛擬機，而非少數四核實體機。鎖競爭與上下文切換抵消增益。 |
| 6 | 64 位 JVM 顯著快於 32 位：Solaris/Linux 均如此 | 64 位指標壓縮、更大堆空間、更佳指令集優化（如更多暫存器）。 |
| 7 | Linux 優於 OpenSolaris x86 | 作業系統排程器、檔案系統、網路堆疊對 JVM 效能影響顯著。 |
Struts：大量使用反射（
Introspector、BeanUtils）映射請求參數 → JavaBean 屬性，同步鎖開銷大。
Tapestry 5：編譯期生成「預編程向量元件」，直接存取屬性，零反射、零同步鎖。
OGNL 教訓：反射本身不慢，慢在「關鍵路徑上的序列存取」。Tapestry 將關鍵路徑靜態化。
BeanModelSource 獲取 BeanModel 後快取重用，避免每次請求重建（供 Grid、BeanEditForm 使用）。tapestry.component-pool-size。tapestry.combine-scripts、tapestry.compress-whitespace。tapestry.production-mode=true 關閉開發期檢查與重載。-d64），堆設定 -Xms4g -Xmx4g 避免擴縮容抖動。replicas: 4, resources: {limits: {cpu: "2"}}）。Tapestry 5 以「編譯期靜態化、零反射、元件池化」三大核心機制，在高併發、複雜表單、記憶體效率上展現優異表現。若應用存在效能瓶頸，90%+ 機率源於業務代碼（N+1 查詢、未快取、阻塞呼叫）而非框架本身。遵循「快取 BeanModel、64 位 JVM、雙核水平擴展、Linux 部署」四原則，可充分釋放框架潛力。
