為什麼您的 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中文網其他相關文章！