performance tuning chapter one
这段时间一直忙于工作，经过漫长的一个多月的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）如果发现有错误，首先最关键的是找到错误日志，应用的也好，应用服务器框架的也好，一定要想办法找到错误日志，这样才能方便分析，靠自己乱猜，是很难找到问题的。