<b>ejb与java序列化(3) 开启enable-call-by-reference</b>[Java编程]

问题终于找到,简单的说是因为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/