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

因为我们现在还没这个需求，所以只是随便看看。留个脚印，有时间再看。

http://www.whalin.com/memcached/javadocs/
但就这么几个client类，使用起来确实方便。
好象好久没更新了。

最近版本是11-27-2005发布，很久了吗？

1，Cookie的大小有限制，所以用Cookie来代替Session有一定的限制。
2，把东西放在Cookie里面不如Session里面安全，无法防止恶意用户修改这些数据。

1.商务信息这些应该持久化，不能放cookie
2.可以用时间戳等方法生成用户登录令牌，这个可以放cookie，同时在服务器端也保持一份--这个可以cache. 每次登录重新生成
客户端cookie可以设置浏览器关闭失效或短时间失效，服务器端也定时清理cache

呵呵，独立的session server可没说怎么保存session啊。

直接文件存贮session也是可以恢复的。

说起来php的session就是可以直接文件存储的。

又绕起来了 ： 内存的Session Cache，然后文件的持久……

就算使用独立Session Server也是可以通过多种手段来提高稳定性的。
就看有没有那么复杂的应用了。

如果访问数据库的代价太昂贵的话，独立Session Server还是有好处的。

访问本地存储仅仅是看起来好而已。
一、分布式的话，缓存是独立机器比较有效，如果还跑其他的应用，天知道会造成什么麻烦。
二、即使应用在同一台机器上，判断本地存储和非本地，然后切换，在实际上操作时问题会比较多，同样不利于分布式。

测试了一下memcached的性能，从我的笔记本电脑连接到Linux Server上面的memcached，存取数据。结果相当满意，速度非常快，如果排除网络通讯的开销，存取cache时间不到1ms，Java已经测试不出来少于1ms的速度了。即使把网络通讯开销一起算上(100MB网卡)，来回存取两次，速度也不到10ms。相信在良好的网络质量下(1G网络)，速度应该更快。


但是我却不得不遗憾的说，memcached不适合Java应用程序！罪魁祸首就是Java序列化机制。

在我的笔记本电脑上Eclipse里面启动jetty5，如果不访问数据库，每次从响应HTTP Request到页面flush完毕，仅仅需要10-30ms的执行时间，即使访问数据库，在数据量很小的情况下，也仅仅需要100-200ms的时间。但是一次Java序列化操作就消耗掉30-50ms！如果每次请求都需要到memcached取得session信息，等于每个请求都要多执行40-60ms，这几乎是不可接受的。

memcached的其他客户端，例如PHP，Perl，Ruby的序列化的开销都不会像Java这样不可想像的昂贵，因此这些应用程序存取memcached完全没有问题，但是唯独Java序列化机制令人难以承受之重！我尝试用反射自己写了一下简单的序列化机制，开销也在15-30ms之间。因此只好放弃memcached。

从这里得到一个教训，凡是依赖Java序列化机制的性能都不会很好，例如很多应用服务器的Session复制就是这样。而我们的Java应用也好，部署方案设计也好，要极力避免操作Java对象序列化。另外值得一提的是，在测试过程中，无意中发现java.util.Calendar的getInstance()方法开销也极大，每次调用竟然需要40-50ms！因此请大家尽量避免使用Calendar，只是使用java.util.Date。

另外我会找时间看看JBossCache，因为jbosscache进行cache同步的时候，并没有采用Java对象序列化，而是使用了class的bytecode操作，传说性能不错。

在这段时间思考群集部署方案的过程中，我逐渐感觉到，由于Java语言的特性和限制，影响到了整个方案的设计。由于Java的对象序列化开销高昂的代价，我不得不放弃集中式Cache Server，而这种方式已经被其他编程语言证明了大容量网站很合理的一种方式。同样的道理，凡是基于对象序列化的session复制方案都不会有很好的性能。所以，在这种情况下，我不得不选择能够session sticky的web proxy，而由于lighttpd尚且不支持session sticky，不得不遗憾的放弃，改而采用apache2.2 AJP。

因而现在的方案改为前端使用apache2.2进行请求分发，配置session sticky特性。后端Java应用程序只允许将用户信息和权限信息放入session，此外不允许session放入其他任何内容。这样也可以达到很好的水平扩展，单个节点的故障只会导致重新从数据库读取一次用户信息。

Robbin的脾气稍微有点大，特别是遇到“不经自己大脑思考的问题”时。但是Robbin对技术的敏锐感觉和钻研精神，还是很让人佩服的。
前几天在网上有人问我Hibernate的lazy和reverse设置，唉，这个问题要说清楚还真不是三言两语办得到，也反过来说明hibernate处理得不简明。
告诉她自己去javaeye上查，过了几分钟又赶紧叮嘱一句：查不出来先问我，再发帖，不然肯定被删^_^

JBossCache有两个组件，一个是TreeCache，另一个是PojoCache(TreeCacheAOP)，前者在集群模式下依赖于序列化，后者不需要。
BengWang有一篇文章介绍了两者在4个节点下的性能对比
http://wiki.jboss.org/wiki/Wiki.jsp?page=WhatShouldWeExpectOfThePojoCachePerformance
我琢磨在网站应用中，吞吐量的差异也就是在1-2倍之间。

1.3.0起的TreeCache集群模式又添加了两个选择： INVALIDATION_SYNC和INVALIDATION_ASYNC(这里所谓的sync和async是指内容复制过程中在通讯过程调用方式上的同步和异步，相当于TCP和UDP的关系).

1.4.0开始，因为1.3.0所表现出来的集群性能问题，居然又有了N多的选项，包括Buddy方式，以及集群复制上的诸多细节选择，一看就晕了。

对于网站应用中用到的集群而言，这个显然是太复杂。大致上INVALIDATION _SYNC模式就够用了(本地cache不命中时首先查询远程cache，仍然不命中后才查询后端存储)。这个时候的jbosscache集群的性能，没有在传说中的复制模式下的那么差。

但是，非常重要的一点，这种写无效模式只能应用在cache的东西肯定有后端存储支撑的情形，或者说它就是一个单纯的cache. 而复制模式，特别是同步复制模式，是可以把cache当作共享存储来玩的.............

以文件方式的cache持续化，在宕机情形中顶不顶用取决于文件系统。
事务型文件系统中才有可能用得上。否则只适用于正常关闭和开启应用服务器的情形