经历性能问题后的一点总结

Reporting项目是我在做的Rails项目，因为性能问题，我们经历曲折坎坷的调优过程，为能否按计划发布而担心。庆祝完发布，我得把一些总结写下来。

故事是这样

• 项目开始于今年三月份，预计在十一月中旬有个大的发布。
• 早在四月份，团队就开始为每个请求、每个查询加benchmark，目的是监视执行时间，但并没有验收条件。
• 八月份，使用Apache Benchmark tool为所有请求在staging环境上做了性能测试，发现有5个图表性能低，甚至在选择地区数目很大(数百个)时，响应时间呈指数增长。之后做了两件事，一是在做功能开发的同时坚持做性能优化，目标就是这些过慢的请求；二是限制地区数目选择的上限到100，以控制最坏情况下的性能。
• 九月份，优化之后对那些重点请求重新进行了并发级别为1的性能测试，结果是响应时间减少了70%~85%，Tom对此很高兴，我们以为性能问题不复存在了。十月二十日，我们开始重新做全面的压力测试，发现一些请求的并发访问性能确实成问题。我们立即告知了客户这个问题。我们没有利用起这期间的时间，发现问题时已经很晚了，离发布只剩1月。
• 接着我们就分析原因，然后就发现数据库的并发查询性能是问题的核心，因为数据库执行时间占了请求响应时间的70%，在并发查询时，数据库反应时间增长地很快，直接导致请求的响应时间增长很快。我们需要DBA帮忙，但Paul的全部时间已经在另外一个项目上了，我们向客户争取来了Paul的部分时间，后来客户为我们安排了另一位DBA专门来帮忙。
• 请DBA帮忙的方式是，我们告诉他某个查询的sql语句，以及目前的执行时间和我们期望的时间，他们来帮忙做优化。这样做的好处是他们立刻知道要干什么，不耽误时间。
• 我们在staging环境上的测试越来越好，理论上产品数据库上的测试结果应更好才对，但是不是这样，惊喜了。在产品数据库上存在一个首次访问响应时间的问题，就是说在时隔若干时间之后的头次访问，响应时间非常慢，但是紧接着第二次访问页面就会很快。这个问题在staging上是没有的，而且我们也无法在产品数据库上重现，不知道这个间隔时间是多少，所以很难请DBA监视。
• 如今，所有查询的优化已经结束了，在产品环境上所有请求在并发测试中的中位数响应时间是在要求之内的。虽然首次访问响应时间的问题还在，但是我们和DBA都没有找到办法能合理地重现它，客户同意的解决方案是：如果需要的话，向用户提示相关信息。
• 昨天成功发布了。

我们学到了什么

如何处理问题？

• 发现问题后，应该及时让客户和DM知道情况，因为这样的问题对项目发布有直接的影响。
• 通过一些手段，比如profiler等工具，来检测应用，诊断出性能问题发生的部位和原因。
• 性能调优需要有一个指标，应该在调优前就向客户、甚至客户的客户要这个指标。不仅要与客户的业务人员谈，还要和技术人员去谈，因为性能指标在这两方人眼中可能差异很大。
• 自己去研究是对的，但应设定时间限制；不应该让讨论只发生在团队内部，应该去请教专家，效率会更高。
• 同时应该让其他项目的同事也了解我们目前面临的问题，因为他们可能就有这方面的经验，也可能以后会遇到相似的情况。
• 对于数据库的问题，我们需要客户的DBA帮忙，一方面要争取他们的时间不断催促他们做事，另一方面要做足准备，告诉DBA最直接的需要做的任务是什么，这样他们也会效率更高。比如告诉他们sql是什么，目前运行时间是多久，期望时间是多久。
• 合理地与客户“谈判”，找到折中的解决方案。这个谈判不是推诿，而是坐在一起讨论，我们的提议要有足够的业务理由做支持。

如何避免问题？

• 我们应该从一开始就把性能纳入考虑，在编写代码时注意到它，而不是专门做优化时被迫重写部分代码
• 我们应该把性能测试和调优的着眼点放在产品环境上，这样可以降低最后得到惊喜的风险
• 我们应该尽早地参考性能指标设计包括压力测试在内的性能测试策略
• 对新版本的探索性测试时，应当对性能表现留心，更早地察觉并意识到问题，这应该叫做持续体验（continuous experience）

当前发布中正在做的事

• 在技术选型时为性能做更多的考虑
• 先做包括可能出现性能问题的故事在内的高风险故事
• 在第一个页面可访问之后就设计性能测试策略
• 在做更多的故事之前就为性能做统筹考虑