我如何将软件系统的性能提高35,000％ _软件系统

文章插图
> An on-call developer's worst nightmare (red indicates errors)

深入探讨如何通过缓存，作业化，队列分离等解决平台的扩展性，稳定性和性能问题。
一天处理超过$ 20,000,000先前的公司建立了用于大规模捐赠日的支付系统和捐赠日软件，在该捐赠日中，我们为一次竞选活动就收到数万笔捐款。
我在那家公司的职责之一是扩展系统并确保其不会倾覆。在最坏的情况下，每秒仅3–5个请求就会崩溃。
由于低效的体系结构，可疑的技术选择以及急速的开发，它具有许多限制，而且是创可贴和巨大的性能差距的拼凑而成。魔咒和咒语的结合将使服务器全天运行。
在使用该平台时，它有潜力每秒处理数千个请求并同时运行数千个广告系列，而所有这些操作的成本大致相同。
怎么样？我会告诉你！
分析使用模式在深入研究如何优化该系统之前，我们必须了解其使用模式以及要在其下进行优化的特定环境和约束，否则将是在黑暗中进行拍摄。
给一天定义了开始和结束

文章插图
> RPS: Giving days started and ended suddenly.

提前几天安排好大规模的计划活动。它们在非常特定的日期和时间开始和停止。有时这些日期是可移动的。有时不是。
强调分享在竞选期间，大力宣传捐赠的努力可能很大。
我们的系统可能在一天的开始就发送数十万封电子邮件，在整个活动期间定期跟踪电子邮件，以鼓励人们参观，参与，共享和捐赠。
社交媒体链接被发布在现有的每个网络平台上的任何地方，其中一些我从未听说过。
整个校园甚至还有实物海报，展位和传单。有些客户甚至在整个24-48期间都进行了电视特辑。
活动既尖刻又恒定鉴于以上所述，我们的资源使用情况可以最好地描述为尖峰和不变。

文章插图
> CPU: mostly constant resource usage with occasional spikes in activity.

在奉献日的某些部分，例如一天的开始和社交媒体的协调推送，我们可以看到活动大量增加。对于单个广告系列，我们可以在不到一秒钟的时间内从每秒0个请求增加到每秒150个请求。这种缺乏加速的行为特征有时可能与DDoS难以区分。
在这些事件之外，资源使用情况是恒定的。当用户与网站互动时，我们将看到捐赠和活动。
最终，当一天结束并且活动全部结束时，活动一开始就突然下降。
有远见的优势由于开始/结束日期是已知的，并且我们与客户紧密合作以找出他们当天的游戏计划，因此它可以为我们的服务器活动提供很多可预测性。这种可预测性允许计划负载。
如果我们知道客户在日常活动中要达到的目标是什么，我们可以通过性能优化和调整服务器设置以最好地管理他们的预期负载来为此做准备。可以通过一些基本计算来相对精确地估计其中的大部分。
我们正在尝试优化什么？现在我们知道要处理的使用方式，让我们简单地回顾一下我们已有的一些指标。请记住，在优化之前，我们应该基准测试并衡量我们能做到的一切。

我们应该忘记效率低下的问题，大约有97％的时间是这样的：过早的优化是万恶之源。然而，我们不应该放弃我们那关键的3％的机会。"
-唐纳德·努斯

正如他们所说："测量两次，切割一次。"
对于我们的系统，我们可以将指标分为两类：
· 衡量活动的指标
· 衡量绩效的指标
测量活动测量活动很重要。这是服务器性能的输入。
每秒的请求很简单。问一个问题：我们的服务器每秒处理多少个请求？更多意味着更多的活动。
CPU使用率是我们密切关注的另一项指标，用于检测系统不可用性。密集的计算会导致系统备份，并且系统不应该首先对Web请求进行密集的计算。
内存使用情况是成败指标。我们的服务器上只有这么多容量。一些低效的代码是内存消耗，将成千上万个对象实例化到内存中。这些内存泄漏被发现并被压缩。
由于我们使用的云服务提供商对连接数量有限制，因此连接计数值得关注。
衡量绩效性能的最大衡量标准是响应时间。降低它意味着我们表现良好，提高它意味着我们表现不好。诸如DataDog或NewRelic之类的APM工具可以向我们展示层级的响应时间，我们可以用来确定瓶颈。