旧一篇: 性能是保障系统生命力的根基！
<script>function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script>场景：（续原文《历史为鉴：稳定高于一切》）
某项目组的系统在培训的时候出现：40个左右的最终用户在操作我们的培训系统时，系统没有了响应，最终用户操作的浏览器一片“空白”，后台服务器类似“挂起”，需要重新启动后台的中间件服务器。
刚开始，项目经理和技术经理对此现象的风险意识不够，在多方教育下，逐步认识到目前发现并且解决问题才是最佳处理事机，等待上了生产系统，由于更多人员使用，会有太多干涉要素会加大分析和解决问题的难度。
经过教育后，项目组投入核心技术人员花了一个星期对问题进行排查：
- 从业务角度，分析是否存在可能培训时，学员都在学习相同的功能点，而该功能点的代码实现存在并发隐患，造成资源阻塞甚至死锁；
- 从技术角度，分析是否存在临界资源没有释放，导致进程阻塞甚至死锁；
- 通过压力测试工具，对可能的情况进行模拟并发访问；
- 通过不同的环境或者参数调整，进行对比检查。
经过压力测试，初步怀疑是没有释放数据库连接造成的，原因如下：
- 压力不大时（客户端请求并发数/数据库连接池最大并发连接数比较小）：连接是会释放的；
- 当压力较大时（客户端请求并发数/数据库连接池最大并发连接数比较大），连接没有释放，通过debug可以跟踪到Apache连接池的wait操作处。程序一直在此等待连接。
由于使用应用程序的程序框架使用OR-Mapping，所以将情况反馈给编写程序框架的同事，由负责程序框架编写的同事介入。我说：“Apache的人不是吃素的，我觉得应该是我们程序的问题。”，同事花了两天的时间把commons-dbcp-1.2.2.jar和commons-pool-1.4.jar的源码给看了一遍，确实没看出什么问题，基本断定是在我们的程序框架中有问题。
最后定位确实是程序框架的问题，并且修复了相应的程序包。报告给我的原因如下：
我们的执行会使用连个连接，一个生命周期长（命令的执行者创建），一个生命周期短（命令执行本身创建使用），生命周期长的必须要等到命令执行完毕才能释放连接，而命令的执行必须要获取到连接，于是生命周期长的获得到了连接，而生命周期短的却拿不到连接，于是就不能执行，于是就停在这里。
有一点在这里要特别强调的是，作为基础框架的编写者，我们要非常重视质量，发现问题其实不可怕，对于出现问题，参与解决的心态以及专业的处理方法。对于一个问题，需要有详细的报告，参照technet.microsoft.com，我们可以将报告分为以下几个部分：
- Symptoms，问题场景；
- How to reproduce，如何重现此问题，可选，方便各个项目自检本系统是否存在此情况；
- Cause，原因分析，可选，如果还没有分析清楚情况，本项内容缺少；
- Status，目前状态，是否已经解决还是未解决；
- Solution，如何解决，可选，如果已经解决或者有替代方案；
- Applies to，影响的范围，什么版本；
由于此案例涉及基础程序框架，因此一定需要详细分析在什么版本开始引入此问题，定位清晰影响的版本，从而可以了解涉及到在建、已建、已投产的客户以及项目的情况，采用积极的方式去解决问题，而不是等待另一个项目反馈才去处理。
发表于 @ 2008年08月08日 16:00:00|评论(2 <script type=text/javascript>AddFeedbackCountStack("2788037")</script> )|编辑|收藏
502
到【灌水乐园】发言
评论
# lunbingtang 发表于2008-11-11 12:13:37 IP: 60.209.231.*-
宝贵经验
# lunbingtang 发表于2008-11-11 12:13:57 IP: 60.209.231.*-
宝贵经验 值得分享