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

但是我却不得不遗憾的说，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。

序列化的开销根要序列化的对象的复杂程度（比如说属性个数，对象嵌套层次等等）和数量有关，“一次Java序列化操作就消耗掉30-50ms”是不负责任说法。
“java.util.Calendar的getInstance()方法开销也极大，每次调用竟然需要40-50ms！” ，要是这样jdk的开发人员该去跳楼了，难道你的机器是286。

测试是在我的IBM T40 PM1.5GHz笔记本上面做的。放在我的AMD 2500+台式机上面，速度更慢，慢40%(Sun JVM估计没有进行AMD指令集优化)。我还没有测试复杂对象的序列化(仅仅测试无嵌套的对象)，就已经开销这么大了。事实上就是这样的，你别光信口开河，用个测试程序测试一下，你就知道究竟是我不负责任，还是你浅薄无知。

robbin说java不适合用memcache,那岂不是用java架构大访问量的网站难度很大,不过,好像也没发现大访问量的网站是用java做的.又没有好的解决办法?或者是比较成熟的解决方案.期待....

....
序列化简单对象开销30-50ms，我很吃惊，我听到了一个比垃圾回收更强的否认java实时编程的理由。给一个java.util.Date实例序列化和反序列化测试程序我看看是如何做的。