周六上午11点，接到领导通知，有个企业自建的测试报表系统加了10w的账号数据后，报表系统点击十多秒才有反应，需要让我协助优化下。
语音和现场人员简单沟通后，发现可能代码逻辑需要改，因为操作是一个系统跳转到另一个系统进行的，我心想 10w账号数据查询应该不会太慢，但是页面请求确实是接近十秒才有响应，而且没有报表数据时也很慢。
让现场的人员看下数据库的慢查询，结果都是很快执行完。排除了sql优化的方式。
因为是自建系统，跟版本库的代码不一定一样，不能贸然从版本库代码直接修改，版本不一致升级出错可就麻烦了。
获取代码还是费了一番周折，搬出大佬一个电话搞定。
接下来就是梳理下代码逻辑，发现里面逻辑为了代码写的精简，使用了好多通用逻辑。还有现场人员的消息时不时催我一下。
还有个问题就是没有测试环境供我调试，立马沟通，还好有一个运维自己搭建的测试环境代码版本是一致的。但是访问服务器和上传文件比较费劲，费劲就费劲点吧，总比没有强。
此时已经是晚上了，优化了一下，没敢太大的改动。发给现场，升级到到企业自建的系统更新后说没反应还是很慢。
因为我测试的系统没有10w账号数据，需要装下优化工具--xhprof
添加模拟数据，操作一下才容易发现问题。
借助这个性能测试工具，可以分析出那些方法调用的多少次，用了多长时间。很快发现了之前的猜测是正确的。通用的逻辑在数据比较多的场景需要优化了。
当时系统设计时应该也没有考虑到这么大的数据量。
优化后升级测试页面返回在1s左右了。