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小时运行的高并发系统，从获得的资料上看，在出现偶发性的性能故障前系统没有做过任何变更，网络也没变更过，业务也没有过大的变动，业务人员的形容是“一夜之间系统就变慢了”，而且该问题在测试机上不能模拟重现。接到任务后，马上进行“望闻问”，都没有太大的收获。进入到“切”环节时，对大量的日志进行跟踪分析调试，最终锁定到了加密机上：加密机属于多个系统的共享资源，当排队加密数据时就有可能出现性能问题，最终的解决方案是增加一台加密机，于是系统性能恢复正常。
1700452169
1700452170
性能优化是一个漫长的工作，特别是对于偶发性的性能问题，不要期望找到“名医”立刻就能见效，这是不现实的，深入思考，寻根探源，最终必然能找到根源所在。中医上有一句话“病来如山倒，病去如抽丝”，系统诊断也应该这样一个过程，切忌急躁。
1700452171
1700452172
注意 性能诊断遵循“望闻问切”，不可过度急躁。
1700452173
1700452174
1700452175
1700452176
1700452178
编写高质量代码：改善Java程序的151个建议 建议135：必须定义性能衡量标准
1700452179
1700452180
出现性能问题不可怕，可怕的是没有目标，用户只是说“我希望它非常快”，或者说“和以前一样快”，在这种情况下，我们就需要把制定性能衡量标准放在首位了，原因有两个：
[
上一页 ]
[ :1.700452131e+09 ]
[
下一页 ]