性能问题定位思路
原则：倒金字塔型，由表及里，逐步聚焦，大胆假设，小心求证
顺序：硬件->操作系统->网络->中间件服务器->应用环境->性能脚本->测试数据->log->profiling(分模块打点监控，工具)
例：搜索线性能问题排查过程
1、排除环境影响
环境主要的排查点为：
1）虚拟内存的使用情况，如果使用超过1m则需要重启服务器；
2）log级别
3）是否使用模板cache
4）jvm参数是否跟线上一致
5）log文件的大小是否超过1G
6）是否有其他服务干扰
2、响应时间和tps
1）在分支中加入时间打点统计，searchweb按时间占用可大致分为：webx框架、业务逻辑java代码、二方库、数据源，对数据源的打点统计确认是否外部依赖的影响，再加上对二方库调用的打点统计，由于webx的耗时是固定的，这时就可确认java代码是否存在问题。一方面开发需要仔细检查代码，也可以结合单元性能测试对java代码的算法进行简单性能测试，还可以使用visualvm等profiling工具对代码的方法进一步做检查。到这里searchweb整个耗时都可以被详细的剖析出来。目前国际站的打点方式为每隔10分钟采样一次，每隔1小时写1次log，所以不会因为打点而影响性能，如果以上打点都覆盖全面，那么跑完2小时就可以看出各模块的时间统计，就可以基本定位出哪一块耗时较多。如果再加上单元性能测试的覆盖，排除java代码算法的性能隐患的话，整个searchweb性能状况就可以比较好的把握了。在国际站推荐引擎的两个项目中，这个排查方法都得到充分的应用，对于缩小问题范围起到了很好的效果。
2）通过调整并发和thinktime等压力参数得到tps拐点，如果仍然达不到预期，可通过上面的方法进一步优化响应时间
3、系统资源指标异常
系统资源涉及到众多的因素，cpu，memory，io，network等，各个因素相互影响，可通过sar，glance plus（此工具可登录10.20.133.167试用，登录后运行glance即可）等工具进行定位
4、系统报错
性能测试前一定要清空之前的log，保证每轮测试log的独立性，测试完成后要详细检查log中的各种ERROR级别的错误，比如
NullPointerException由于高并发导致的空指针错误必须要调查清楚
性能问题定位方法
