性能是保障系统生命力的根基！

 某项目的事件：

1. 7月21日周会，业主接口人投诉我们的系统性能差，在某功能建立一个数据需要大半个小时；
2. 7月28日周会，业主接口人再投诉，QA查看现场发现显示系统首页大于5秒，查看某个常用浏览功能打开需要大于5秒，并告知我们刚才看到的情况算是较好情况，并且告知已经投诉很久了，之前给我们销售的同事和部门经理都投诉过，但是我们一直没有响应不多，QA告知业主：“我现在也没有办法向你承诺，但是我能够告诉你，你反应的情况，我一定认真处理！”
3. 8月4日周会，业主接口人谈到某功能，发布数据，需要接近十分钟；另外，在业主的本市另外一个办公地点，最终用户反馈上线试运行的系统基本很难帮到他们，但是在开会的办公地点，好像使用起来，没有那么明显；另外，项目经理汇报进行SQL优化，发现有执行超过1分钟的SQL语句。
4. 上周，部门经理向QA确认，负责服务维护的同事向项目经理反映过系统的性能问题，但是项目小组还没有反馈；
5. 上周，项目经理去另外一个办公地点的现场进行使用培训时，使用生产系统，在按按钮或者切换页面的时候，有明显“页面空白”的迟缓表现，在培训中，出现“头脑空白”、找其他话说的情况；
6. 培训时，最终用户反馈系统很难帮助他们，有最终用户说，这个还不算慢的，我们使用的另外一个系统更慢；

跟进情况：

1. 项目小组从7月28日起，开始重视问题，安排专人进行跟进，跟进结果，初步认定：
   1.1 客户端的js脚本文件、css等客户端文件的比较大，为了减少网络传输的时间，准备使用http协议的压缩方式进行优化；
   1.2 客户端的js脚步文件、css等客户端文件没有设置缓存；根据分析，系统刚上线的时候是有设置静态文件的客户端缓存，但是由于一段时间更新比较频繁，由于客户端有缓存，导致客户的投诉，因此将静态页面的缓存关闭。
   
2. 8月4日带同事去现场感受，他初步认定除以上同事的认定外，追加了以下的认定：
   2.1 有些页面引用了不必要的客户端脚步；
   2.2 有些页面存在不必要的刷新，导致页面重新装载；
   2.3 有些页面存在不必要的<table>嵌套，导致页面展示慢；
   2.4 业主告诉他在某办公场所不算太慢，但是在另一个地方反馈慢；因此认定是网络问题；
   2.5 建议加上缓存看看；

点评：

1. 现场排查很重要，到最终用户的现场，真正体验最终用户的感觉，比在开发环境中猜测有效得多；
2. 要排除心理关口的障碍，培训时既然有用户反馈我们开发的另一个系统使用起来更慢，我们更应该去看看他的使用环境，拿到一手的资料；
3. 象福尔摩斯一样，去找出各种蛛丝马迹，可以怀疑一切，但是只能用数据来证明怀疑，侥幸心理要不得，业主告诉你的每一句话，都需要佐证，不能简单地因为可能一个地方不慢，就认定是网络问题，有可能压根现在就没有人用我们系统，就你在用所以觉得不慢呢！
4. 对比方法是一种常用的定性手段，如果我的同事能够将一台手提电脑放到服务器所在相同的网络环境，在客户端访问这台手提电脑的脚步文件，发现也是反应很慢，我可能会相信可能存在网络问题；
5. 除了定性外，定量的证明是需要扎实的技术功底来保证。本案例中，如果基础扎实，知道HTTP协议并没有定义静态内容比动态页面优先，因此大大存在动态页面的执行时间过长而导致静态页面的传送时间长的可能；如果基础扎实，知道只需要对Web Container进行监控，并且对Access日志进行分析是可以较快地定性以及定量瓶颈在何处，我们还可以提高效率。
6. 缓存冲突是每个系统设置缓存时就必须考虑的要素，没有案例说明因为可能需要打Hotfix，所以系统就不能设置缓存！只能说明以往的部署方案没有认真考虑缓存的配置，而且缓存的配置随着系统的生命周期也时需要动态调整的。
7. 我们急需对java的Web开发同事开展性能调优的培训课程，让他们了解影响Web应用性能的各个要素，并且掌握一些基本的排查方法。

以上案例目前还在跟进中，我们的培训准备还未完成前，欢迎感兴趣的同事询问性能优化的问题。