JRockit 5.0 + Tomcat with APR

这两天遇到一个问题。在一个流量比较大的生产环境上，只有一台服务器，跑的是Debian Sarge，内核是2.6.12的，用Apache 2.2 + mod_proxy，后面拖叻三个Tomcat 5.5。在Tomcat没有使用apr的情况下，基本上给多少个线程就满多少个线程，访问速度狠慢，情况狠糟糕。于是我将三个Tomcat都配置上apr，启动后却发现ajp的端口无法启动，紧接着jrockit就崩溃，打印一堆信息。

后来没办法，马上换SUN JDK 1.5.0_06，再无问题。三个Tomcat也跑的狠欢，正在执行中的线程数从原来的几百降低到十几二十几，系统负载从100多200多降低到4。

结论：

1、还是不敢轻易使用JRockit。也许JRockit性能更加出色，但是在兼容性和稳定性方面还是SUN JDK最好。JRcokit只有对几个专门的系统做过优化（如RHEL），在其它系统上，真的是会有问题。

2、Tomcat在配上APR之后性能非常强劲。可以断定以往Tomcat的性能瓶颈就是出在socket的分发调度上，而APR在这方面是非常优秀的。所以Tomcat与APR的结合，我认为非常好，做生产环境非常棒。

3、Apache 2.2加上mod_proxy为系统提供叻非常有效的负载均衡手段，想带几个tomcat就带几个，硬件资源被充分利用。以往预计起码要两台机器才能撑的住的应用现在用一台就跑的非常好。

我记得以前看tomcat5.0.x的文档上面说，在超过两个以上的tomcat实例之间进行HttpSession的复制，效率是很低的，因而建议cluster不使用超过两个实例。你挂3+的tomcat实例，HttpSession复制情况怎么样？

根本就不用Session啊，强制要求的，明令禁止的。我一直不明白，为啥老去考虑Session复制这种恶心的情况，不去用Session不就行叻。cookie挺好的。

实际上任何app server间的session复制开销都狠大。本身对象序列化开销就大，再用网络去传（搞不好又要走RMI，天啊），再反序列化……

我在windows下jrockit+tomcat+apr好像没什么问题。

是的，我以前做过tomcat session replication，性能是很低下的。而且我session replication这样的方案，完全可以采用cookie或cache+db来实现

没错没错

那JVM级别的缓存同步怎么办？干脆也不做缓存了？

用cookie是不是会有安全上的问题？

正常情况下，session在服务器端维持，客户端维持一个session id的cookie，假设服务器端session里面有两个key，“userId”和“isAdmin”，前者是用户的登录ID，后者是超级管理员标记。
即使session id被截获，那么通常情况下，被截获的是普通用户，那么攻击者并没有获得全部权限。

在不使用session的情况下，就需要两个cookie，“userId”和“isAdmin”（除非每个请求都到数据库查询一次，该用户是否admin），这样攻击者非常容易自己伪造userId和isAdmin这两个cookie而获得系统的最高权限。

虽然可意对cookie做一些处理，比如不用有意义的名字，做加密等等。但是这里描述的只是一个最简单的情况，在实际系统中，情况还要复杂，如何维持好这么多cookie的安全问题呢？

Robbin讲的是 像Hibernate的一级缓存吧?基于Session Replication来实现 JVM 级别的缓存也是很困难的。

我觉得基于Cookie和Cache+db方案要尽量避免 JVM cache...

的确很多情况下，Cookie方案的安全性问题是需要在设计中好好考虑的环节。
Cookie由于在客户端可以查看的到，一般就放置一些不重要的信息或一次性、临时的凭证信息（加密、随机的），而重要的信息是需要放置在服务器端的（如Cache、Memory或db中），客户端需要传递这个凭证信息来获取服务器的重要信息，这种情况下，攻击就很难伪做。。。