LoadRunner性能测试引发的内存溢出(续)-DWR代码分析
2012-09-29 19:58
405 查看
接上一篇深入分析DWR代码的处理逻辑,仅保留了说明问题的主干代码;
先看DWR的相关数据结构:DefaultScriptSessionManager中有两个相对重要的ConcurrentHashMap:sessionMap和sessionXRef,
sessionMap 以ScriptSessionId为key保存ScriptSessionId与ScriptSession的关系;
sessionXRef 以SessionID为key保存SessionID和ScriptSessionId的关系(见后面的代码);
ScriptSession 则是通过内置的一个attributes Map保存其归属的SessionID;
当httpRequest被BaseCallHandler类的handle()方法处理时,DefaultWebContext类的checkPageInformation()方法被调用,而后者又调用了DefaultScriptSessionManager类的getScriptSession()方法;
从代码可以看出sessionMap首先保存ScriptSessionId与ScriptSession的对应关系,再通过调用associateScriptSessionAndHttpSession()方法在sessionXRef中保存SessionID和ScriptSessionId的关系;超时检查方法checkTimeouts稍候描述;
DefaultScriptSessionManager的getScriptSession()方法首先执行Timeout的检查,遍历sessionMap中的ScriptSession,超时的ScriptSession会被标记随后执行invalidate()方法;
invalidate()方法中首先进行sessionMap的清理,再调用disassociateScriptSessionAndHttpSession()方法清理sessionXRef;
LoadRunner脚本提交http请求时使用了固定的几个ScriptSessionId,从而导致Tomcat内存溢出,gc无法回收;
综上所述,sesssionMap中只会保存LoadRunner脚本中设置的ScriptSessionId;事实上,脚本中一共使用了7个ScriptSessionId,检查堆内存dump对象后,sessionMap中确实也就只有7条数据;
当携带相同ScriptSessionId的请求到来时,sessionMap中保存的ScriptSession会被更新:lastAccessedTime,SessionID,由于lastAccessedTime不停的被更新,从而导致ScriptSession始终不会过期,而SessionID的更新导致sessionXRef中旧SessionID对应的ScriptSessionIds再也无法回收;sessionXRef中为每个SessionID保存了7个ScriptSessionId;
只有把LoadRunner停止,等待一段时间,可以观察到ScriptSession过期的日志;sessionMap中的数据被正常清理,而sessionXRef中的最后一批SessionID的数据也会被清理,但是GC对上面所说的老SessionID对应的ScriptSessionIds无能为力;可以看下老生代内存对象做个证明;正如前面所分析的,每个SessionId下有7个ScriptSessionId;
先看DWR的相关数据结构:DefaultScriptSessionManager中有两个相对重要的ConcurrentHashMap:sessionMap和sessionXRef,
sessionMap 以ScriptSessionId为key保存ScriptSessionId与ScriptSession的关系;
sessionXRef 以SessionID为key保存SessionID和ScriptSessionId的关系(见后面的代码);
ScriptSession 则是通过内置的一个attributes Map保存其归属的SessionID;
当httpRequest被BaseCallHandler类的handle()方法处理时,DefaultWebContext类的checkPageInformation()方法被调用,而后者又调用了DefaultScriptSessionManager类的getScriptSession()方法;
从代码可以看出sessionMap首先保存ScriptSessionId与ScriptSession的对应关系,再通过调用associateScriptSessionAndHttpSession()方法在sessionXRef中保存SessionID和ScriptSessionId的关系;超时检查方法checkTimeouts稍候描述;
DefaultScriptSessionManager的getScriptSession()方法首先执行Timeout的检查,遍历sessionMap中的ScriptSession,超时的ScriptSession会被标记随后执行invalidate()方法;
invalidate()方法中首先进行sessionMap的清理,再调用disassociateScriptSessionAndHttpSession()方法清理sessionXRef;
LoadRunner脚本提交http请求时使用了固定的几个ScriptSessionId,从而导致Tomcat内存溢出,gc无法回收;
综上所述,sesssionMap中只会保存LoadRunner脚本中设置的ScriptSessionId;事实上,脚本中一共使用了7个ScriptSessionId,检查堆内存dump对象后,sessionMap中确实也就只有7条数据;
当携带相同ScriptSessionId的请求到来时,sessionMap中保存的ScriptSession会被更新:lastAccessedTime,SessionID,由于lastAccessedTime不停的被更新,从而导致ScriptSession始终不会过期,而SessionID的更新导致sessionXRef中旧SessionID对应的ScriptSessionIds再也无法回收;sessionXRef中为每个SessionID保存了7个ScriptSessionId;
只有把LoadRunner停止,等待一段时间,可以观察到ScriptSession过期的日志;sessionMap中的数据被正常清理,而sessionXRef中的最后一批SessionID的数据也会被清理,但是GC对上面所说的老SessionID对应的ScriptSessionIds无能为力;可以看下老生代内存对象做个证明;正如前面所分析的,每个SessionId下有7个ScriptSessionId;
相关文章推荐
- LoadRunner性能测试引发的内存溢出 - 善用日志
- LoadRunner性能测试样例分析
- Loadrunner性能测试结果进行分析
- [性能测试] LoadRunner结果分析 – TPS(转)
- 【软件性能测试-LoadRunner实战技能 18】== LoadRunner_常用函数分析
- LoadRunner性能测试样例分析
- LoadRunner性能测试结果分析
- LoadRunner性能测试指标分析
- LoadRunner性能测试指标分析
- LoadRunner性能测试关注指标及结果分析
- loadrunner性能测试结果分析总结
- 【软件性能测试-LoadRunner实战技能 14】== LoadRunner_Web_reg_save_param function explained_分析
- LoadRunner性能测试工具---(二)测试结果分析
- 【软件性能测试-LoadRunner实战技能 4】== 监控指标数据分析
- LoadRunner性能测试样例分析
- LoadRunner做性能测试 从设计到分析执行
- LoadRunner性能测试指标分析
- LoadRunner性能测试指标分析
- LoadRunner性能测试工具---(三)测试结果样例分析
- JS性能分析(测试代码运行时间)