關於sitemesh，不過多介紹，不知道的請google之，簡單來說就是做總體頁面佈局和渲染用的,如頁面中的header,footer等。 


今天內部討論中，有工程師談到使用sitemesh的建議。我之前做的一個網站也是使用sitemesh，在開發效率上還算不錯，可以讓大家更專注於各自的模組頁面。當時sitemesh效能上並沒有問題。當時的效能瓶頸主要出現在過多hibernate關聯資料查詢上，後來快取解決之。 


另外也有同事提出反對意見：使用sitemesh對於系統性能是有較大的影響的，主要表現在GC的次數會顯著增多。建議在大壓力、頁面內容大的系統中，慎重選擇sitemesh，並且使用之前對其帶來的效能影響進行一個較為合理、全面的評估。 


我們當前的專案情況:開發進行到一半，正進入套美工介面階段，所以出現以上問題場景和選擇。有同事說：架構師配置之。我以前也有使用過sitemesh,引入到當前專案也是可行的。但需要一個評估和兩天左右的引入工作量。還好有另外的同事反對，正好找到藉口暫時不使用。我倒不是怕一兩天的工作量，我是覺得在開發進行中，每引入一個新的技術或者團隊不熟悉的東西，都會增加專案失敗的風險，特別是前期沒有很好的規劃時。所以暫時只用include解決之。一來大家都熟悉，使用也簡便，二來從效能上也如同事說的那樣。 


當然，效能也並沒有同事說的那麼可怕。 
一來，對於頁面內容大的問題，因為sitemesh是以空間換時間，web伺服器加點記憶體就完事，現在記憶體超級便宜。
二來，web應用的瓶頸不在乎那點絕對效能。對於併發壓力大，一個tomcat也就能支援幾百併發，瓶頸在tomcat這塊，頁面再快也沒用。解決方案一般是負載均衡和應用叢集。 


大家可以聊聊在web應用中，使用sitemesh的經驗。當然也可以談談其它的方案。但是不做為其次選擇的參考，因為技術風險擺在第一位，不會輕易在專案過程中引用新技術。 


最後附上網友做的sitemesh效能測試評價： 
http://www.iteye.com/topic/715100

我們開發組合頁面用sitemesh不多，經常使用freemark，就不做評價了。
在“大壓力、頁面內容大的系統中”應使用各種快取技術可以大幅度減少邏輯處理次數，所以sitemesh即使有一些效能問題也無傷大雅。
比起Java，ruby和php等指令碼語言的效能要低上不少，但基於這兩種語言的高效能網站卻比比皆是。系統級別的優化很多時候會比語言/框架本身帶來更大的收益。