打字猴:1.700452131e+09
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
1700452177 编写高质量代码:改善Java程序的151个建议 [:1700438211]
1700452178 编写高质量代码:改善Java程序的151个建议 建议135:必须定义性能衡量标准
1700452179
1700452180 出现性能问题不可怕,可怕的是没有目标,用户只是说“我希望它非常快”,或者说“和以前一样快”,在这种情况下,我们就需要把制定性能衡量标准放在首位了,原因有两个:
[ 上一页 ]  [ :1.700452131e+09 ]  [ 下一页 ]