performance tuning chapter one

16 Feb 2013

这段时间一直忙于工作,经过漫长的一个多月的tunning,差不多有了些结果,现记下一些个人关于performance tunning的感想,为自己,也为别人。

find . -name “error log”

之前花了不少时间在找问题原因,是关于tps达标,但错误率一直上不去的问题,分析既然有错误,按理说应该好办,但之前一直没有发现程序后台的错误log,故一直认为是什么网络原因等,怀疑这怀疑那,基本等于没多少头绪乱碰那种,因而耽误了不少时间,后来无路可走,才又重新认真找了一次log,终于发现了,那么,之前为什么一直找不到了,因为我们的系统是多台blade组成的cluster,错误只发生在其中的某一台blade,而之前又天真的以为在其中两台都没找到log就放弃了,其实log是最重要的troubleshooting工具,所以千千万万都不要放弃找log,找到了log就等于找到了救命稻草。OK,那么找到log之后呢,一定要找最开始错误日志,因为可能由于一开始的错误从而导致接二连三的其他错误,千万不要被这些其他的错误所迷惑而偏离了方向,找到最开始的错误日志,分析原因,先不要管后面的那些错误,可能是雪崩效应引起的其他问题。那么最终找到这个问题出在哪里呢?这里也想多说几句,找到错误日志分析后,得出应该是在新建数据库连接时,发现新建不了连接,分析得出原因可能有2个:一个是数据库和应用的网络有问题,第二个是因为走的VIP,所以可能是VIP出去到数据库的连接有问题,因为VIP是我们自己做的,所以先怀疑这个VIP,如果是网络问题,那么也不好fix,最终发现的确是VIP的问题。而我想说的是,就是由于这个数据库连接建不成功,会导致其他好几种的错误,但根源就是这一个。

./perf4J

说到分析,工具比不可少,个人感觉perf4J这个工具不错,之前用过2,3次,觉得挺方便,也较易于找到应用代码上的问题。当然了,这次也不例外,先大致在关键方法代码上打上@Profiled,放上去(对于这个放上去,稍后会继续说到),再测,看哪里延时多,再细分代码,厚丝剥茧,逐层加监控,再测,如此下来几次,也可大致找到延时多的code。

./fast-redeploy-tool

上面也提到用perf4J修改完代码后,如果放到服务器上去的问题,因为会频繁改动代码,所以“放上去”这个耗时的操作也很重要,借此,也推销下自己做的一个小工具fast-redeploy-tool,它会自动扫描改动代码,打包,传上服务器,重新打包,部署,这样,一个繁琐的“放上去”就可以简化成点几下鼠标,敲两下键盘的事情了,提高了效率,救了大量脑细胞,真是perf4J的好拍档啊。

./summary

总结一下,几点:1)performance tuning一般都不止是一个问题这么简单,一般都是几个问题混杂在一起,需要耐心,逐个击破;2)找到可靠的tuning tools,一般不需要怀疑这些tools,至少不到万不得已的时候;3)如果发现有错误,首先最关键的是找到错误日志,应用的也好,应用服务器框架的也好,一定要想办法找到错误日志,这样才能方便分析,靠自己乱猜,是很难找到问题的。