朝着同一服務器的CURLOPT_CONNECTTIMEOUT和CURLOPT_TIMEOUT的良好生產價值

Question

我希望我的問題不要太隨心所欲：在生產服務器上，我有一個頁面，使用cURL將API調用發送到同一服務器上的另一個應用程序。

我想先在CURLOPT_CONNECTTIMEOUT上設置適當的值，然后在CURLOPT_TIMEOUT上留出足夠的時間以確保在有大量請求的情況下完成請求，但是同時我不希望頁面在API關閉或關閉的情況下掛起。需要太長時間才能做出響應，這將導致所有用戶的重大滯后，因為將會產生龐大的陣容。

該API可以進行非常快速的數據庫查詢，並返回一個小的json結構，沒有什么復雜的事情需要花費很多時間。

有了這些規范，有人可以對此發表評論嗎？ 我目前有：

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($ch, CURLOPT_TIMEOUT, 4);

更新 ：

• API是全新的，僅供我使用
• API是獲取所有數據的關鍵。 如果API不起作用，則無任何作用，並且顯示錯誤消息
• 在每個頁面上運行API以獲取所需的數據

Answer 1

定義這些值時，需要考慮許多因素。 但是，對於HTTP請求（第一個字節），可以認為2秒是可以接受的。 如果管理HTTP請求起源的服務器，則還應考慮服務器資源，例如內存，CPU，IO，Web服務器配置。 但是一般來說，您應該考慮在端點上運行traceroute以更好地了解延遲-這將幫助您為CURL定義更准確的超時值。 當然，最后，如果您要從服務器發起許多請求，則應該考慮前面提到的服務器的相同資源限制。

希望這可以幫助！ 請參閱以下博客： https : //www.inmotionhosting.com/support/website/how-to/read-traceroute

Answer 2

您需要了解有關該API行為的信息，以便做出有根據的決策。 它還取決於在您的代碼中如何使用該API以及在發生故障時所需的行為。

考慮：

• 如果將該值設置得太低，則由於任何原因API花費更長的時間響應，您的代碼都會失敗。
• 如果API的響應時間超過〜4秒，那是什么意思？
  • API是否完全關閉？ 那么實際上您不需要等待更長的時間。
  • 它超載了嗎？ 那它會在5秒鍾內回復嗎？ 6？ 10？ 這種過載狀態將持續多長時間？ 通過重載更多代碼來復合它是否不好，或者盡早中止代碼並讓API恢復會更好嗎？
  • 是否有臨時網絡啟動？ 如果您將超時時間設置為5秒，是否可以解決？ 10？ 20？ 網絡通常有多可靠？
• 如果API由於上述任何原因而響應緩慢，您希望應用程序運行緩慢還是死機 ？
• 您可以保證 API的一定響應時間嗎？如果不能保證該響應時間，那就意味着它已經關閉了？

• 您面向用戶的網站的目標響應時間是多少？

  網絡超時通常在30到120秒之間，這可以補償臨時的網絡問題，但仍在人工范圍內。 用戶的注意力通常會在幾百毫秒后漂移，因此您希望將響應時間保持在一秒以內。 但是，等待網站加載幾秒鍾並不罕見。

如果您需要調整這樣的關鍵參數以找到最佳設置，那么務實的方法是將其設置為某個初始值，安裝一些測量工具以監視吞吐量和響應率，並啟動模擬的壓力測試預期的生產水平負荷。 然后，您將看到錯誤和響應率上升或下降，並且可以調整設置，直到找到滿足所需約束的值為止。