关于rails大容量网站部署的性能讨论

Memcache的Java Client貌似有性能问题
http://hi.baidu.com/jabber/blog/item/a6b8af86d292543e67096e91.html

贴一点MyFaces的代码（javax.faces.component.html.HtmlInputSecret）:

public [b]Object[/b] saveState(FacesContext context)
{
[b]	Object values[] = new Object[28];
	values[0] = super.saveState(context);[/b]	values[1] = _accesskey;
	values[2] = _alt;
	values[3] = _dir;
	...
	values[27] = _title;
[b]	return ((Object) (values));[/b]}

public void restoreState(FacesContext context, [b]Object state[/b])
{
[b]	Object values[] = (Object[])state;
	super.restoreState(context, values[0]);[/b]	_accesskey = (String)values[1];
	_alt = (String)values[2];
	_dir = (String)values[3];
	...
	_title = (String)values[27];
}

然后用C++ << 和 >>方法，可能能解决！

貌似 TestBean 里加了个这个

private static final long serialVersionUID = 176966201487084843L;

跑出来大多是0，也有15、16ms

如果不加，基本31ms以上

按说 Stateless EJB 之类应该是用来封装 业务逻辑运算 的, 被放在 表现层 和 数据持久层 之间, 而且可以由专门的硬件服务器资源来独立执行. 按JavaEE的思路, 表现层 和 服务层 应该是可以剥离的, 从Robbin的群集方案来看, 大家实际做的时候, 好像只是在逻辑上把它们分开了, 从 运算资源 的角度看, 它们其实还是一层, 也就是 Web处理 层. 然后业务逻辑 主要还是在 Web处理 层实现, 对 数据库 还基本是存取操作.

可能因为一直以来数据库就总是用来做数据存取而已的, 用 SP 实现业务逻辑基本都是被抵制. 这种情况下数据库服务器的运算压力不算大, 计算量大部分在 Web处理层.

如果在 可执行运算强度 的分布上需要把 服务层 再分离出来单独做群集的话, 似乎 JavaEE 就显得相对成熟灵活了. 不过是不是 表现层 的逻辑太简单了, 让 服务层 完成业务逻辑运算以后稍带脚儿执行一下就行了, 所以才变成现在这样了?

j2ee用台10机器可以完成的，它就得用20台甚至更多？是不是这个意思

robbin说的不错.解决性能的方案很多,语言解决不了的,自己想办法总能绕过去的.

我现在做过的项目还没有用到过集群

不懂，为什么要加这个？也曾在代码中加过

这个和性能无关吧

这个帖子，让我看了4个多小时，但真的很精彩。