关于使用sitemesh的性能评价及选择

关于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等脚本语言的性能要低上不少，但基于这两种语言的高性能网站却比比皆是。系统级别的优化很多时候会比语言/框架本身带来更大的收益。

sitemesh.没听过，准备学习一下

sitemesh真正好用的场景还是类似面包屑风格的导航条,导航条一般的布局都会在公用头文件里,但是他的内容在不同页面里又是不一样的,这个时候使用sitemesh就好用

另外曾经在早期的jira代码里看到了sitemesh的变态应用,他们所有的form都是通过sitemesh的二次decorator来生成的.

一个tomcat也就能支持几百并发？？

这个表示怀疑啊