隨著時間的推移響應時間變慢，從哪裡開始故障排除？
當我提出這個問題時，我的 IT 人員只是聳了聳肩，所以我向 SE 尋求幫助。
我覺得這張圖最能說明問題。
很簡單，隨著時間的推移，響應時間變得越來越差，直到午夜左右的某個時間發生了一些事情，並且幾乎恢復到正常水平。我們在 IIS 上，這個頁面恰好仍然在 Classic ASP 中，但這發生在所有頁面上，即使是純 HTML 頁面，我認為這排除了 SQL 連接問題。
我想我的問題是，我從哪裡開始尋找？我瀏覽了正常日誌，並沒有看到任何突然出現在我身上的東西。但顯然有些事情正在發生，我不知道從哪裡開始。
導致這種情況的原因有很多——不幸的是，我們可能需要更多資訊。
在我進入我的實際響應之前，先簡單介紹一下您的 HTML 頁面：一般來說，應用程序池一次只能響應一定數量的請求。如果它忙於響應對動態頁面的請求，那麼它可能沒有任何執行緒可以為靜態頁面提供服務。出於這個原因，動態頁面上的程式碼問題會造成靜態頁面服務“緩慢”的錯覺。我的觀點是，不排除程式碼或 SQL。
**例如：**如果您有 100 個頁面同時訪問數據庫或 API，並且所有 100 個頁面都在等待響應，則請求 101 可能會被阻止，直到前 100 個頁面中的一個完成。
現在，您可以做很多事情來幫助您診斷此問題：
- 您的負載配置文件通常是什麼樣的？這會產生很大的不同——您可能總是遇到問題，但在您的網站實際收到負載之前您看不到影響。您可以嘗試使用 JMeter 之類的東西來測試它（在 staging 中）。
- 啟用 IIS 日誌（如果您還沒有），然後查看它們以查看哪些請求花費的時間最長。您可以使用類似Log Parser（來自 Microsoft）之類的工具對您的日誌執行類似 SQL 的查詢（甚至將您的日誌轉儲到 SQL 數據庫中），如果這樣可以讓生活更輕鬆。一旦您知道哪些頁面花費的時間最長，您就可以將一些注意力集中在它們上。
- *您的應用程序有日誌嗎？*如果沒有，您應該考慮添加一些日誌記錄。如果您已經有日誌，他們會說什麼？您的應用程序是否拋出異常？有什麼東西一直在失敗嗎？
- 您的應用程序池使用了多少記憶體？記憶體洩漏是一個明顯的候選，但你應該很容易看到。使用 Windows 的內置性能監視器來跟踪您的應用程序池在一天內消耗的記憶體，並查看這是否隨著時間的推移而增加。
- 正如我在開篇中提到的，SQL 可能仍然是一個問題。我建議查看數據庫伺服器，看看是否有任何長時間執行或阻塞的查詢（例如在 中，
sys.dm_exec_requests查看wait_type、和）。wait_time``blocking_session_id``total_elapsed_time- 使用TCPView（另一個 Microsoft 工具）之類的工具*檢查您的應用程序池打開了多少連接。*您的應用程序池將嘗試在可能的情況下重用連接，但您可能會看到許多與您的應用程序池的打開連接。您可以從中看到一件有趣的事情，現在您已經打開了許多連接到您的 SQL 數據庫或您的應用程序使用的任何外部 API。
- *使用應用程序性能和監控工具。*AppDynamics 或類似工具將能夠幫助查明程式碼中執行緩慢的部分。不幸的是，要有效地使用這些工具需要一點學習曲線，但它們在幫助診斷應用程序問題方面非常強大。
更新
如果您有記憶體洩漏，重新啟動您的應用程序池可能有助於解決問題，但您需要注意這一點：可能會有一些不利影響。重新啟動應用程序池後，應用程序將開始將靜態對象載入到記憶體中，等等。根據應用程序的複雜程度，這可能需要很長時間（可能是 5-10 分鐘或更長時間）。在此期間，對您伺服器的請求可能會延遲，從而使問題看起來更加嚴重。
如果您正在執行單個伺服器，則您的站點可能會在應用程序重新啟動時暫時不可用（由於應用程序池正忙，並且無法響應請求）。如果您使用負載均衡器在場中執行，則負載均衡器可能會在應用程序池重新啟動時將您的伺服器退出，這可能會將所有流量引導到其他伺服器並使其過載。不要同時在所有伺服器上重新啟動應用程序池，並在將伺服器重新引入伺服器場之前嘗試“預熱”應用程序池（通過模擬對伺服器的請求）。
**換句話說：**除非它絕對是記憶體洩漏的問題，否則可能不值得重新啟動應用程序池，因為問題可能會立即重新出現。
注意：重新啟動應用程序池不會影響任何目前正在執行的請求。這些將繼續完成，除非您強行關閉應用程序池（例如
Crtl++Alt）Del