创作者 ｜ Itamar Lechowicer

译员 ｜ 许学文

方案策划 ｜ Tina

校审 ｜ 李明

文中最开始发表于 Itamar Lechowicer blog，经创作者受权由 InfoQ 中文站翻译工作并共享

概 述

大家企业运维管理着 15 个 Web 运用，关键的工作任务便是按需交货根据数据驱动的 Web 应用软件，用以支撑点即时管理决策的制订。

这种运用的预估是在高负荷下仍然维持高可用性。在其中的主 Web 运用是一个历史时间遗留下的大中型多服务项目系统。系统中的绝大多数服务项目都是有超出 15 年的历史时间而且通过了好几代人的重新构建。设想一下，承担撰写系统代码的人如今也许早已辞职或早已调节到别的职位了。

以往两年大家精英团队的具体目的是便是对于这种服务项目开展性能提升。此次我将与你介绍在性能提升的历程中，大家的一些关键经验交流和那时候决策那么做的缘故。

认知能力更改时时刻刻

在一次恶性事件中，客户提升了对大家运用的利用率，造成大家运用的手机流量大幅度提升。在这里事情全过程中，客户埋怨大家的运用性能确实很差，以致于没法在运用上进行整套的工作流程。因此，大家逐渐运用监管专用工具剖析运用的性能短板。根据运用监管专用工具，大家看到服务项目在获得 DB 联接上耗费了 90% 的反应时间。

可是 DB 看起来一切正常，因此，大家逐渐剖析运用的 DB 数据库连接池。剖析发觉，全部的 pod 将数据库连接池中所有可以用的联接都采用了。因而大家猜想服务项目在关掉联接上很有可能有什么问题。因此，大家花了几小时時间查验代码，试着寻找联接沒有被释放出来的地区。最后，大家的一个 TeamLeader 发觉，pod 的生存探头在做一次简易的 DB 心脏跳动要求以后沒有释放出来 DB 联接。接着，大家马上在 pod 生存探头的要求中提高了一行用以释放出来 DB 联接的代码。危害是吓人的。眨眼睛间，运用的性能就逐渐趋于稳定而且客户也修复了一切正常应用。

就在本次事情的前一天，大家才实行过一次负载测试，以保证应用软件可以承担预计的需求量提高，检测结果显示运用的性能是在正常的范畴内的。殊不知事实上这一检测结果是失误的，不正确的检测结果欺诈大家认为应用软件沒有必须修补的问题。大家深刻理解到了不正确，大家必须做得更强。下列是我们在本次恶性事件中了解到的一些工作经验和汇总。

总结一：不必应用均值等待时间做为考量服务项目负荷的技术指标——审查运用的“尾端”值

当客户埋怨运用回应慢的情况下，大家发觉均值等待时间指标值并没显著的转变。在我们回望了这种指标值数据信息的情况下，留意到了一些有意思的事：以前我们都是将均值要求時间做为服务项目等待的首要指标值，因而，此次大家将 90% 要求等待时间的数据信息干了一个数据图表，看一下这一数据图表能否意见反馈些信息内容。果然，在客户埋怨运用慢的情况下，大家观查到数据图表中等待时间大幅度提升。均值等待时间指标值往往沒有显著转变，是由于过多的迅速要求将均值拉出来了。因此我们建议是，不应用均值等待时间，而应用 50%，90%，95%，99% 的均值等待时间做为服务项目回应的指标值。审查这些远远地超出标准值标准的“尾端”值是十分关键的。

汇总二：在性能提升上资金投入時间、专用工具和人力资源

要维持使用的高性能，大家务必具有下列标准：

负载测试和负荷情景——具有可以用的负载测试和负荷情景十分关键。

运用监管专用工具（APM）——例如 Dyanatrace，AppDynamics 和 Epsagon 等专用工具。APM 在监控服务上可以帮大家节省很多的時间。因而在工作环境安裝最少一个 APM 是十分需要的。

合理的日志——高效的日志是制造服务项目终断调研和性能问题调查的基础标准。因而你务必保证运用的日志是清楚且有效的。

日志分析工具——你不能从许多文档中载入和检索日志，特别是在如果你的服务项目是群集的情况下，根据文档载入日志将变的愈发艰难。因而，花时间建成投产一个例如 ELK，Grafana 或 Splunk 的日志回收器和分析工具是十分需要的。

技术专业的人力资源支撑点——针对以上提及的专业知识或是专用工具，假如你的精英团队沒有相应的专业性人才，那麼你将哪些也干不了。

因而，对于繁杂的系统，我建议资金投入专业的人与的时间来解决。（例如，SRE 精英团队就能有效的担任各项任务）

汇总三：老系统可能衰落（除非是大家激话他们）

做为人们，大家都是有造就新生事物的不理智和冲动，而且对造就出来了的商品有一种使用权感。在系统的全世界里，在人们必须处置的分歧中，有时也会包括那样的分歧。一方面，有一个老系统必须大家维护保养；而另一方面，有一个酷炫的新系统大家需要去开发设计。那麼这个时候，大家就必须决策将時间资金投入到那片。在我们应对那样的纠纷时，大家需要记牢，如果我们不再次在老系统上完成研发和加上新作用，那麼对老系统的掌握会伴随時间的变化而消退。因而，在我们应对系统常见故障或顾客新要求时，因为缺乏对老系统的掌握或是工作能力问题，将没法达到总体目标。也就是说，在我们丧失针对老系统的认识以后，系统的 MTTR(均值修补時间) 升高了。

因而，我们建议是，要常常抑制要想造就一个新的、酷炫事情的不理智，将時间资金投入到对老维护保养系统的了解和提高解决困难的工作能力上。此外，维持对老系统了解度的最好方法便是试着在老系统中加上代码。

结果四：每一行代码都很重要

有时候，在我们在撰写代码的情况下，大家也许会忘掉这种代码最后运作将在工作环境中，并为一个真正客户的真正工作中服务项目。上边提及的大家亲身体验的实例中，只不过是由于程序猿忘记了释放出来 DB 联接（一行代码罢了），就可以影响一个客户的常规工作中（这些工作中受影响的客户可能很不愿意给大家付费）。

我们建议是：

想像一下（尽管难以），在世间的另一端，某一客户的作业彻底依靠你撰写的代码，与此同时设想一下，你写的每一行代码都将直接影响其应用运用的感受。

在 CI 或是 CD 阶段实行负载测试。假如你要保证代码高可用性，那麼就对于每一个将要建成投产的 PR 或版本号都开展负载测试。

如果你发觉性能问题的情况下，请猜疑每一行代码——据人们的工作经验，代码中的每一个标识符都是有可能是造成性能的短板。

总 结

此文章内容论述了我们在系统性能提升上的所有成功经验和心得体会，希望根据此文章内容可以协助你意识到系统性能缺点所具有的不确定性风险性。

我觉得，运用的性能应当被视作最大优先选择解决事宜。由于和终端产品用户不可以应用系统对比，好看的 UI 和酷炫的商品都看起来无足轻重。

我写的这种结果全是我依据日常性能提升的工作经验总结而成，因而，我认为，上边的全部结果全是每一次取得成功的性能提升的根基。因此，我就期待你可以发觉他们的用途。

https://medium.com/@ilechowicer/how-every-code-line-matters-we-improved-performance-by-3000-c9ce858c39a8