为什么您的 FastAPI（或 Flask）应用程序在高负载下表现不佳

首先，为标题诱饵道歉？，但我昨晚解决了这个问题，而且我仍然受到多巴胺激增的影响。我只是想分享这个。

本文面向入门级开发人员或数据科学家（而不是高级 Python 软件工程师），我会将其写为叙述性内容，或者换句话说，按照事件发生的时间顺序排列，而不是“技术论文” （以问题、解决方案、讨论为结构）。我喜欢这种方法，因为它展示了现实生活中事情是如何发生的。

初步考虑

这些测试是在 GCP Cloud Run 上使用单处理器和 512M RAM 机器完成的，我们使用了 Locust，这是一个令人难以置信的工具（对于 Python，哈哈）。

此外，如果您在 Postman 上的单个请求上已经遇到性能问题，我强烈建议您看一下这个致力于提高 Kisspeter 的 FastAPI 性能的存储库以及来自 LoadForge 的这个存储库。

第一轮测试

在 Postman 中使用单个请求，Cloud Run 启动后，我得到了大约 400 毫秒的响应时间。不是最好的，但完全在可以接受的范围内。

我们的负载测试非常简单：在一个表中读取、写入和删除（或对 API 端点进行 GET、POST 和 DELETE）。 75% 读取，20% 写入，5% 删除。我们在 100 个并发用户的情况下运行 10 分钟。

最后我们得到了 2 秒的平均响应时间，但最令人不安的部分是测试结束时平均时间仍在增加，因此在稳定之前（并且如果）该数字很可能仍会增加更多.

我尝试在我的机器上本地运行它，但令我惊讶的是，Postman 的响应时间只有 14 毫秒。然而，当运行500个并发用户的负载测试时，问题又出现了？ ...

到测试结束时，响应时间约为 1.6 秒，并且仍在增加，但出现了一些故障，第 95 个百分位数飙升（并破坏了图表 =( )。以下是统计数据：

现在，为什么响应时间为 14 毫秒的服务器在只有 500 个并发用户的情况下突然达到 1.6 秒？

我的机器是酷睿 i7、6 核、2.6GHz、16Gb RAM、SSD。这不应该发生。

给我一个很好的提示的是我的处理器和内存日志......它们非常低！

这可能意味着我的服务器没有使用我机器上的所有资源。你猜怎么着？事实并非如此。让我向您介绍一个绝大多数开发人员在将 FastAPI 或 Flask 应用程序部署到生产环境时忘记的概念：流程工作人员。

根据 getorchestra.io：

了解服务器工作者

服务器工作人员本质上是运行应用程序代码的进程。每个工作人员一次只能处理一个请求。如果您有多个工作人员，您可以同时处理多个请求，从而提高应用程序的吞吐量。

为什么服务器工作人员很重要

• 并发：它们允许并发处理请求，从而更好地利用服务器资源并加快响应时间。
• 隔离：每个worker都是一个独立的进程。如果一名工作人员出现故障，不会影响其他工作人员，从而确保更好的稳定性。
• 可扩展性：调整工作人员数量可以轻松扩展您的应用程序以处理不同的负载。

实际上，您所需要做的就是将可选的 --workers 参数添加到服务器初始化行中。您需要多少工作线程的计算在很大程度上取决于运行应用程序的服务器以及应用程序的行为：尤其是在内存消耗方面。

这样做之后，我在本地为 16 个工作人员获得了更好的结果，10 分钟后收敛到 90 毫秒（对于 500 个并发用户）：

最后一轮测试

使用适当数量的工作线程配置微服务后（我的单处理器 Cloud Run 实例使用了 4 个），我在 GCP 中的结果非常好：

在GCP服务器测试结束时最终值收敛到300ms，至少是可以接受的。 ？

以上是为什么您的 FastAPI（或 Flask）应用程序在高负载下表现不佳的详细内容。更多信息请关注PHP中文网其他相关文章！