JNDI查找时间的巨大差异

Question

我们在Weblogic 10.3上运行的遗留J2EE Web应用程序的响应时间差异很大.该系统由两个Weblogic服务器实例(前端和后端)组成,它们运行在同一个物理服务器计算机上,另一个Oracle数据库运行在单独的主机上.每次登录系统需要超过四秒钟时,外部测量工具会提醒我们.最近这些警告频繁发生.查看处理登录请求的servlet所写的日志会显示从前端到后端的EJB调用所花费的时间.

测量时间示例:

time    ms   
8:40:43 25
8:42:14 26
8:44:04 26
8:44:25 26
8:44:47 26
8:46:06 26
8:46:41 7744
8:47:00 27
8:47:37 27
8:49:00 26
8:49:37 26
8:50:03 8213
8:50:57 27
8:51:04 26
8:51:06 25
8:57:26 2545
8:58:13 26
9:00:06 5195

可以看出,大多数请求(70%,来自更大的样本)及时完成,但其中很大一部分需要很长时间才能完成.

在测量时间内执行的步骤如下:

• 提供身份验证接口(前端)的会话bean的JNDI查找
• 调用会话bean的身份验证方法(frontend-> backend)
• 从连接池(后端)保留JDBC连接
• 对用户数据库进行查询(表大小非常适中,表应该正确编入索引)(后端)
• 读取结果集,创建POJO用户对象(后端)
• 返回POJO用户对象(后端 - >前端)

服务器计算机上的负载非常小(空闲率为99%),用户数量非常适中.两个服务器上Weblogic报告的可用内存量在60%到90%之间.记录垃圾收集.主要藏品很少见,并且在发生时会在2-3秒内完成.此外,主要的GC出现似乎不会在看到长响应时间的同时发生.繁忙和非繁忙时段都会出现较长的响应时间.JDBC连接池最大大小当前设置为80,大于并发用户数.

更新:

获得了重新启动系统的权限,并添加了更多性能日志记录.日志清楚地显示JNDI查找是花费时间的部分:

03:01:23.977 PERFORMANCE: looking up foo.bar.Bar from JNDI took 6 ms
03:14:47.179 PERFORMANCE: looking up foo.bar.Bar from JNDI took 2332 ms
03:15:55.040 PERFORMANCE: looking up foo.bar.Bar from JNDI took 1585 ms
03:29:25.548 PERFORMANCE: looking up foo.bar.Bar from JNDI took 7 ms
03:31:09.010 PERFORMANCE: looking up foo.bar.Bar from JNDI took 6 ms
03:44:25.587 PERFORMANCE: looking up foo.bar.Bar from JNDI took 6 ms
03:46:00.289 PERFORMANCE: looking up foo.bar.Bar from JNDI took 7 ms
03:59:28.028 PERFORMANCE: looking up foo.bar.Bar from JNDI took 2052 ms

查看前端和后端的GC日志显示,当发生慢速JNDI查找时,GC未完成.

创建会话时,上下文的方式如下:

Hashtable ht = new Hashtable();
ht.put(Context.PROVIDER_URL, url);
ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
jndiContext = new InitialContext(ht);

其中url是一个t3 url,指向后端服务器的DNS名称和端口.这应该没问题吧？

要记住的第一件事是缓存从JNDI获得的引用,至少这是10年前的首选方式......但是不应该Weblogic的InitialContext实现已经执行了这个缓存,或者它是否真的从中获取引用每次通话后端服务器？

什么可能导致频繁的慢速JNDI查找？有没有解决方法(例如缓存参考帮助)？

Answer 1

那么可能导致这种相当不稳定的行为呢？

我们说的任何话都可能是猜测.这里有一些调查问题的建议,而不是玩那个游戏:

• 尝试使用分析器查看花费的时间.
• 尝试使用网络工具(如WireShark)查看是否存在异常网络流量.
• 在关键点添加一些日志记录/跟踪,以查看时间的进展.
• 寻找Thread.sleep(...)电话.(哎呀...这是猜测.)

Answer 2

作为第一步，我将尝试通过记录每个步骤所花费的时间来隔离执行的这些步骤的哪一部分导致了问题。这样你就可以消除不相关的事情并专注于正确的领域，当你弄清楚时可以再次在这里发布任何内容，以便人们可以提供具体的建议。