使用 Python 和 Django 每秒处理 100 个请求

通常，我们的博客侧重于广告、隐私以及我们围绕这两者的交叉点建立业务的旅程。这篇文章将深入探讨我们在使用广告服务器时遇到的一些技术和扩展挑战。我们的广告服务器的正常吞吐量峰值约为每分钟 3,500 个请求，即每秒 60 个请求。小滴是晚上，大滴是周末。在 2019 年末之前，Read the Docs 上的广告由一个 Django 应用程序提供，该应用程序实际上是 Read the Docs 代码行的一部分。我们知道我们想将其分解为一个单独的服务，以准备启动我们的广告网络。但是，过程有点棘手，因为我们知道在第一天，这个新服务器需要每秒处理大约 20-30 个请求，而流量高峰可能会使这个数字达到 60 或更高。为此，我们不懈地专注于我们的应用程序性能。有趣的是，Python 和 Django 不被认为是性能最好的语言和框架。我们不想从头开始重写，但是，在性能更高的语言中。也强烈希望使用类似的设置来阅读Docsas 这就是我们的小团队（当时有 5 人）非常了解的。为了提高性能，我们实际上花了很多时间在 Django 调试工具栏中挖掘 New Relic 跟踪和检查每个 Postgres 查询。对于像我们这样的广告服务器，只有几个不同的 API——比如请求广告和查看广告--几乎所有事务的帐户。我们甚至进行了单元测试，以确保这些 API 中的数据库查询数量不会发生变化。当我们非常确信广告服务器已准备好以代码方式上线时，我们进行了一些负载测试以确保它可以处理流量。在最初推出期间肯定有一些错误的启动，最后我们决定把它通过了满载测试。为了确保我们能够处理部署广告服务器后我们知道将要看到的负载，我们对 Heroku 和 Azure 的 AppService 进行了临时部署，以比较它们的性能。鉴于此应用程序是从一开始就与云无关。之后，我们使用 siege 来测试部署在各种负载下，每秒最多 100 个广告请求。这些是真实的请求，就像我们在生产中看到的一样，我们想看看 staging 将如何应对.

这是一个非常标准的 Heroku 设置，用于处理性能繁重的应用程序。我们在各种吞吐量下对其进行了测试，但它能够每秒处理 100 个请求而不会丢弃请求。然而，我们确实看到我们的第 99 个百分位性能 (p99) 爬升到了550-600 毫秒的范围非常糟糕。在 Heroku 上，100 个并发请求也会让我们遇到一些更昂贵的 Redis 和 Postgres 设置来处理超过 100 个连接。在这个例子中，我们将配置增加了一倍多。这个设置表现得更好，虽然它似乎不是完全线性更好，这有点奇怪。我们的 p99 在每秒 100 个请求的设置中接近 350 毫秒，但它没有t 丢弃任何请求。中值性能 (p50) 在 80-90 毫秒内保持大致相同。这是 Azure 中与 Heroku 设置相当的设置。我们运行完全相同的代码，并且配置尽可能接近。我们测试了不同数量的实例，并且性能与实例数量成线性关系。性能要好得多p50 约为 75 毫秒，而 p99 大幅提升至约 200 毫秒。即使在更长和更大的测试中（在某些情况下有更多实例），我们也发现 AppService 上的性能比 Heroku 上要好得多。负载测试的最终结果是，我们在 AppServicewhere 上启动了广告服务器，获得了可预测的性能和合适的成本。Heroku 在易于部署方面绝对胜出，并且具有很多优势和灵活性。然而，对于这种类型的在性能和可预测性至关重要的应用程序中，AppService 是正确的选择。根据我们当前一周的表现，New Relic 报告了 58 毫秒的 p50 和 105 毫秒的 p99。在将事情推出生产几个月后，我们遇到了 AppService 的一些问题。作为回应，我们切换到自动缩放的 VM 缩放集。使用相同的围攻设置，我们能够显示 VM 缩放集（我们也在阅读Docs) 不仅扩展得更好，而且比我们的 p50 减少了大约 15 毫秒。我们不确定为什么它们更快，但我们认为这是 AppService 和容器化的一些开销。这听起来并不多，但当你考虑到我们没有更改任何数据库或广告服务器代码。除了在异常负载下，我们通常会扩展到大约 3-4 个实例。我们做了一些进一步的优化，比如减少对 Redis 的缓存请求（最快的请求是你不需要发出的请求）。目前，大约 20 毫秒的正常请求在 Python 中被占用，而其余的在 Postgres 和 Redis 中被消耗.这显示了任何框架或语言优化的上限。Django 和 Python 可能会很慢，但替换它们最多可以将我们的性能降低 10-15 毫秒。改进我们的基础设施或我们处理数据的方式会产生更好的结果。

我们的服务器时间有一半多一点花在 Postgres 上，而 Python 则不到一半 我们的下一个扩展挑战是如何在不同的大陆上获得良好的性能。我们可以随心所欲地优化服务器性能，但由于欧洲和亚洲要差 80-100 毫秒纯粹是为了延迟。目前，我们的事实来源是 Postgres 数据库中的内容，重新设计解决方案以在边缘实际处理广告请求将是一个很大的变化。这将比 CDN 边缘缓存更复杂，因为我们的大多数请求都涉及 DB写入。数据库的多写入器方案绝非易事。感谢您与我们一起踏上建立道德广告网络的旅程以及随之而来的技术挑战。如果您对我们的产品或服务有任何想法或反馈，请给我们发电子邮件。我们总是很乐意收到您的来信。