ejb与java序列化(3) 开启enable-call-by-reference

问题终于找到，简单的说是因为java 序列化的效率低下，而ejb调用之间又大量使用序列化，因此造成极大的性能消耗，而且也影响到响应时间。仔细分析了一下项目情况，呵呵，情况非常严重，系统架构是按照三层来设计的，每个层都是ejb，调下一层都是通过远程接口，而且层之间可能还多个ejb的调用。

（说句题外话，这种设计个人感觉非常，恩，不理解，性能杀手，而且ejb配置极其复杂，当然或者ejb本来就是如此，ebj和weblogic对我来说是很陌生很高深的东西，目前还没有深入掌握。）

很自然的会想到ejb2.0中的配置项enable-call-by-reference，如果能够开启就可以避免远程接口调用中的序列化。检查配置文件发现几乎能设置enable-call-by-reference的地方都设置为true了，奇

怪，再检查部署方式时发现，恩，晕倒，被部署到不同的ear包中了。

不同的ear包，enable-call-by-reference就算设置位true也开启不了吧？

接下来的改进方式，很自然就想到，如果能打包到同一个ear中，就可以在不改动代码，不改动部署文件的情况下解决这个问题，似乎是一个不错的好想法。

谨慎起见，同时为了拿到足够的证据来说法上层，先做个试验先。

模拟公司的项目结构，单独写了一个project，1个servlet负责接受外界请求，3个SLSB模拟三层工作，ejb直接只提供远程接口，然后打包到同一个ear包进行测试。当然enable-call-by-reference设置为true

和false来进行对比测试。

为了突出这个差异，ejb中都不进行任何操作，也不sleep。这样消耗就主要体现在java 序列化的消耗上，而且为了模拟真实情况，参数设置的比较大，里面放了1000个instance。

使用loadrunner，开启100个测试线程，通过http访问servlet，测试时间一分钟，看能执行多少次请求，测试结果如下：

enable-call-by-reference = false : 558

enable-call-by-reference = true : 21163

由于这个结果的差异性实在是太大了，因此没有必要进行多次测试，近40倍的差异完全可以反应问题了，当时实际项目中应该远没有这么夸张。

总结一下：

1. java serialize 非常慢

2. enable-call-by-reference可以有效避免这个开销

因此，能enable-call-by-reference就尽量enable-call-by-reference。

ps:顺便将这个测试的eclipse project也分享出来吧，请在这里下载

http://www.fs2you.com/files/045b367d-5d23-11dd-a2ed-0014221b798a/

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!