前段时间不久,我一直在开发的一个上海科箭物流系统 突然用户传来性能上的不稳定,问题接踵而来,页面打不开,页面超时等等。
在遇到这个问题的时候,由于系统没有日志记录,所以要想知道到底是什么原因影像了这个系统,真的有点困难。
<script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>
我们拿过来了用户的IIS日志开始分析,发现有用户的出错页面集中在10来个页面,错误消息是500,这个是IIS日志分析下载
根据这些页面,我们本地进行了详细的测试,发现了一些小问题,但根本的原因还是没有找到。
为了解决这个问题,项目经理特地跑到客户的现场蹲点1个周,一天下午,大家开了一个远程会议,一起在现场跟踪问题,最后不是CPU死锁,内存占用太多,也不是带宽不够,发现了是一个接口程序嫌疑最大
大家一起仔细分析这个接口程序,发现这个程序在跑动的时候,有大量的更新表操作,而用户出错的这几个页面都会操作这几个表,问题应该解决了,还有待客户的反馈。
也许最头疼的问题就是不知道问题的原因,所以,在分析问题的时候一定要冷静O(∩_∩)O
本文描述了一次针对上海科箭物流系统的性能问题排查过程。在没有日志记录的情况下,通过分析IIS日志定位到频繁出错的页面,并最终发现了一个进行大量表更新的接口程序可能是导致性能下降的根本原因。

被折叠的 条评论
为什么被折叠?



