增加了一行代码，让我们提高了3000%的性能
时间：2023-02-16 09:30:01
作者 ｜ Itamar Lechowicer
译者 ｜ 许学文
策划 ｜ Tina
审校 ｜ 王强
本文最初发表在 Itamar Lechowicer 博客由原作者授权 InfoQ 翻译和分享中文站
概 述
我们公司运维 15 个 Web 应用程序，主要工作是基于数据驱动的按需交付 Web 支持实时决策制定的应用程序。
这些应用程序的预期是在高负载下保持高可用性。 Web 应用程序是历史遗留下来的大型多服务系统。系统中的大部分服务都超过了 15 多年的历史，经过几代人的重建。想象一下，负责编写系统代码的人现在可能已经离调整到其他职位。
在过去的几年里，我们团队的主要目标是优化这些服务的性能。这一次，我将与您分享我们的一些主要经验总结和当时决定这样做的原因。
认知改变时刻
在某一事件中，用户增加了我们应用程序的利用率，导致我们应用程序的数据流量显著增加。在此事件中，用户抱怨我们的应用程序性能太差，无法完成应用程序中的一整套业务流程。为此，我们开始使用监控工具来分析应用程序的性能瓶颈。通过应用监控工具，我们发现服务正在获得 DB 连接消耗 90% 响应时间。
但是 DB 看上去一切正常，所以，我们开始分析应用的 DB 连接池。分析发现，一切 pod 使用连接池中所有可用的连接。因此，我们猜测服务在关闭连接方面可能存在问题。因此，我们花了几个小时检查代码，试图找到连接未释放的地方。最后，我们的一个 TeamLeader 发现，pod 做一个简单的生存探针 DB 心跳请求后未释放 DB 连接。然后，我们马上就来了 pod 存活探针的请求中增加了一行用于释放 DB 连接代码。影响是可怕的。转眼间，应用程序的性能开始稳定，用户恢复正常使用。
就在事件发生的前一天，我们进行了负载测试，以确保应用程序能够承受预期的使用增长。测试结果表明，应用程序的性能在正常范围内。然而，事实证明，测试结论是错误的，错误的测试结论误导了我们认为应用程序不需要修复的问题。我们对错误有着深刻的认识，需要做得更好。以下是我们在这次事件中学到的一些经验和总结。
总结一:不要用平均等待时间作为衡量服务负荷的指标——检查应用程序的尾部值
当用户抱怨应用程序响应缓慢时，我们发现平均等待时间指有明显变化。当我们回顾这些指标数据时，我们注意到了一些有趣的事情：我们以前把平均请求时间作为服务等待的主要指标，所以这次我们会 90% 要求等待时间的数据做一个图表，看看图表是否能反馈一些信息。果然，当用户抱怨应用缓慢时，我们观察到图表中等待时间急剧增加。平均等待时间指数之所以没有明显变化，是因为太多的快速请求降低了平均值。因此，我的建议是使用它而不是平均等待时间 90%，90%，95%，99% 平均等待时间是服务响应的指标。检查远远超出正常值范围的尾部值是非常重要的。
总结2：投入时间、工具和人力进行性能优化
为了保持应用程序的高性能，我们必须满足以下条件：
负载测试和负载场景-负载测试和负载场景非常重要。
使用监控工具（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
技术交流群
最近很多人问有没有读者交流群，想知道怎么加入。
最近创建了一些群，大家都可以加入。交流群是免费的，加入后不要随便发广告，多交流技术就好。
目前，全国交流群、北上广杭深等地区交流群、面试交流群、资源共享群已成立。
对入群感兴趣的学生，可长按扫描下方二维码，注：全国 Or 城市 Or 面试 Or 资源，根据格式备注，可以更快通过并邀请进入群。
▲长按扫描
往期推荐满嘴骚话HR。。。
Spring Boot 3.0.0 发布第一个里程碑版本M1，你的 Java 升到 17 了吗？
研究生写脚本抢HPV九价疫苗：被采取强制措施，后果严重
如果你喜欢本文,
请长按二维码，关注 Hollis.
转发至朋友圈，是对我最大的支持。
点个 在看
喜欢是一种感觉
在看是一种支持
↘↘↘
