捲曲返回間歇性「連接失敗 - 無錯誤」

Question

我們在公司網絡中的非互聯網服務器上有兩個應用程序。一個應用程序（客戶端應用程序）通過API從另一個應用程序（服務器應用程序）獲取數據。

客戶端應用程序使用PHP庫Jyggen \ Curl調用API。週五，用戶開始報告客戶端應用程序的錯誤。當我檢查錯誤日誌，我可以看到的是，捲曲的請求被間歇性的錯誤而失敗：

Failed connect to server-app:80; no error

我能夠通過點擊客戶端上不同的網頁應用程式自己要重現此 - 最終API調用會失敗而PHP lib會拋出一個異常。錯誤繼續今天，我也能夠使用curl.exe從命令行重現它 - 我必須執行命令10-15次才能得到錯誤，但它最終發生了。

服務器應用程序也直接由用戶在他們的瀏覽器（以及通過API）訪問，我們在那裏沒有問題。

根據客戶端應用程序的使用情況，Curl錯誤似乎是在一天中最繁忙的時段（英國時間上午9點至下午3點）發生的。這兩個應用程序都在IIS上運行，並且有足夠的最大併發用戶數。

此刻我的兩種理論：

1. 網絡問題 - 企業的IT也看不出什麼錯然而
2. 捲曲的問題 - 是有什麼我不知道關於有多少捲曲的請求可以在任何時候製作？我們的用戶數量在過去幾個月中一直穩步增長，因此我們可能剛剛觸及引發問題的臨界點？如果這是相關的，我們不使用curl_multi。

任何提示/想法要檢查下，將不勝感激。

更新

我設法今天上午重現錯誤在我的瀏覽器。我檢查了IIS日誌，並且當時是唯一使用客戶端應用程序的人（沒有其他人使用它的時間超過10分鐘）。因此，我的意見是建議客戶端應用上的流量不是一個因素。

Answer 1

（爲什麼人們堅持在過於複雜的OO包裝非常明智的API嗎？）

這是不是一個真正的編程問題 - 這是關於故障查找和最有可能的一些基礎設施相關的問題。

如果客戶端無法連接，則連接被拒絕或超時。您應該有足夠的信息來確定適用於此的信息。

如果連接被拒絕，那麼不會有明顯的延遲。您需要查看拒絕連接的情況（在沒有代理或IPS的情況下，這將是IIS實例）並找出原因。

如果連接超時，那麼問題可能是網絡上的數據包丟失或遠程服務器出現問題。增加連接超時將有助於後者。開始收集客戶端連接所需的時間，並查看是否存在任何模式（檢查與其他事件（如備份）的相關性）。如果沒有任何明顯的模式/增加timneout沒有幫助，那麼這是一個丟包問題。