我們正在運行一個 Flask 應(yīng)用程序來公開存儲在數(shù)據(jù)庫中的數(shù)據(jù)。它返回很多503錯誤。我的理解是，當(dāng)達(dá)到最大并發(fā)線程數(shù)時，這些是由 apache 生成的。根本原因很可能是應(yīng)用程序性能不佳，但在這個階段，我們無法承受更多的開發(fā)時間，所以我正在尋找一種廉價的部署配置技巧來緩解這個問題。數(shù)據(jù)提供者正在以高速率發(fā)送數(shù)據(jù)。我相信他們的程序得到了很多，503只是嘗試/抓住那些重試直到成功。數(shù)據(jù)消費者以低得多的速度使用該應(yīng)用程序，我希望他們不要被這些問題所困擾。我正在考慮限制來自每個提供商的 IP 的并發(fā)訪問數(shù)量。他們可能會獲得較低的吞吐量，但他們會像以前一樣忍受它，這將使休閑消費者的生活更輕松。我確定了似乎為此而定制的mod_limitipconn。mod_limitipconn [...] 允許管理員限制來自單個 IP 地址的同時請求的數(shù)量。我想確定我了解它是如何工作的以及如何設(shè)置限制的。由于 WSGI 設(shè)置，我一直認(rèn)為最多有 5 個同時連接：threads=5. 但是我在 mod_wsgi 文檔中閱讀了進(jìn)程和線程，我很困惑?？紤]到下面的配置，這些假設(shè)是否正確？一次僅運行一個應(yīng)用程序?qū)嵗?。最多可以產(chǎn)生 5 個并發(fā)線程。當(dāng)處理 5 個請求時，如果第 6 個請求到達(dá)，客戶端會得到一個503.將 apache 級別對 IP xxxx 的同時請求數(shù)量限制為 3 將確保該 IP 只能使用這 5 個線程中的 3 個，將 2 個留給其他 IP。增加 WSGI 配置中的線程數(shù)可以通過提供更細(xì)粒度的速率限制來幫助在客戶端之間共享連接池（您可以將 4 個提供者中的每一個限制為 3 個，并保持 5 個，總共 17 個），但不會改善整體性能，即使服務(wù)器有空閑內(nèi)核，因為Python GIL 阻止多個線程同時運行。將線程數(shù)提高到 100 之類的高數(shù)可能會使請求更長，但會限制503響應(yīng)。如果客戶端將自己的并發(fā)請求限制設(shè)置得不太高，甚至可能就足夠了，如果沒有，我可以使用類似mod_limitipconn.過多地增加線程數(shù)會使請求變得很長，以至于客戶端會超時，而不是503這樣并不是更好。