1700452119
1700452120
如果项目组的技术能力很强，有资深的数据库专家，有顶尖的架构师，也有首席程序员，那性能问题产生的根源就应该定位在无意识的代码缺陷上。
1700452121
1700452122
如果项目组的文化氛围很糟糕，组员不交流，没有固定的代码规范，缺乏整体的架构等，那性能问题的根源就可能存在于某个配置上，或者相互的接口调用上。
1700452123
1700452124
如果项目组已经习惯了某一个框架，而且也习惯了框架的种种约束，那性能的根源就可能是有人越过了框架的协约。
1700452125
1700452126
需要注意的是，“闻”并不是主动地去了解，而是由技术（人或应用）自行挥发出的“味道”，需要我们要敏锐地抓住，这可能会对性能分析有非常大的帮助。
1700452127
1700452128
（3）问
1700452129
1700452130
“问”就是与技术人员（缔造者）和业务人员（使用者）一起探讨该问题，了解性能问题的历史状况，了解“慢”产生的前因后果，比如对于业务人员我们可以咨询：
1700452131
1700452132
性能是不是一直这样慢，从何时起慢到不能忍受？
1700452133
1700452134
哪一个操作或哪一类操作最慢，大概的等待时间是多长？
1700452135
1700452136
用户的操作习惯是什么，是喜欢快捷键还是喜欢用鼠标点击？
1700452137
1700452138
在什么时间段最慢，业务高峰期是否有滞顿现象，业务低谷是否也缓慢？
1700452139
1700452140
其他访问渠道，如移动设备是否也有效率问题？
1700452141
1700452142
业务品种和数量有没有激增，操作人员是否大规模增加？
1700452143
1700452144
是否在业务上发生过重大事项或重要变更，当时的性能如何？
1700452145
1700452146
用户的操作习惯有没有改变，或者用户是否自定义了某些功能？
1700452147
1700452148
而对于技术人员，我们就要从技术角度来询问性能问题了，而且由于技术人员对系统了如指掌，可能会“无意识”地回避问题，我们应该有技巧地处理这类问题，例如可以这样来询问技术人员：
1700452149
1700452150
系统日志是否记录了缓慢信息，是否可以回放缓慢交易？
1700452151
1700452152
缓慢时系统的CPU、内存、I/O如何？
1700452153
1700452154
高峰期和低谷时业务并发数量、并发交易种类、连接池的数量、数据的连接数量如何？
1700452155
1700452156
最早接到用户投诉是什么时候，是如何处理的，优化后如何？
1700452157
1700452158
数据量的增长幅度如何，是否有历史数据处理策略？
1700452159
1700452160
系统是否有不稳定的情况，是否出现过宕机，是否产生过javacore文件？最后一次变更是何时，变更的内容是哪些，变更后是否出现过性能问题？操作系统、网络、存储、应用软件等环境是否发生过改变？
1700452161
1700452162
通过与技术人员和业务人员交流，我们可以对性能问题有一个整体认识，避免“管中窥豹，只见一斑”的偏见，更加有助于我们分析和定位问题。
1700452163
1700452164
（4）切
1700452165
1700452166
“切”是“四诊”的最后一个环节，也是最重要的环节，这个环节结束我们就要给出定论：问题出在什么地方，该如何处理等。Java的性能诊断也是类似的，“切”就要我们接触真实的系统数据，需要去看设计，看代码，看日志，看系统环境，然后是思考分析，最后给出结论。在这一环节中，需要注意两点：一是所有的非一手资料（如报告、非系统信息）都不是100%可信的，二是测试环境毕竟是测试环境，它只是证明假设的辅助工具，并不能证明方法或策略的正确性。
1700452167
1700452168
曾经遇到过这样一个案例，有一个24小时运行的高并发系统，从获得的资料上看，在出现偶发性的性能故障前系统没有做过任何变更，网络也没变更过，业务也没有过大的变动，业务人员的形容是“一夜之间系统就变慢了”，而且该问题在测试机上不能模拟重现。接到任务后，马上进行“望闻问”，都没有太大的收获。进入到“切”环节时，对大量的日志进行跟踪分析调试，最终锁定到了加密机上：加密机属于多个系统的共享资源，当排队加密数据时就有可能出现性能问题，最终的解决方案是增加一台加密机，于是系统性能恢复正常。
[
上一页 ]
[ :1.700452119e+09 ]
[
下一页 ]