在很長的響應時間，應用程序池回收結果

Question

我在什麼地方閱讀，啓用時重疊的應用程序池回收應該不是很明顯給最終用戶，但對我來說，在至少10倍以上的結果反應比通常情況下（取決於負載，響應時間從正常100ms增長到5000ms）。此外，這不是一個單一的請求，而是池回收後的幾個請求（我在測試時使用了〜10個併發連接）。

所以問題是：

1. 在我看來我沒有做任何事情，這將需要在應用程序啓動時間長 - 在一般情況下，僅僅是IoC容器和路由初始化，也連我會做點什麼 - 這是重疊應該照顧還是不重視？
2. 游泳池循環中被摧毀的SQL連接池會是爲響應時間長的一個原因？
3. 什麼是最好的方法來分析這麼久什麼考慮？也可能有想法，從IIS/.NET方面可能需要這麼長時間，以及如何避免這種情況。

Answer 1

1. 只重疊意味着舊的工作進程將繼續運作，而新的開始。一旦新的開始，它就開始處理所有請求。 「開始」並不意味着初始化（可能包含在的Application_Start，在您的應用程序的任何靜態構造函數，或任何時候，有爭議的任務，如代理大樓）已經完成。這意味着即使「舊」工作進程可能在短時間內仍然可用，新的請求將不得不等待這些進程完成。此外，如果您的應用程序使用任何類型的緩存，則新緩存將「冷」，這意味着緩存預熱之前還需要一些額外的處理時間。

2. 是 - 你的新的應用程序將有一個新的SQL連接池。

3. 根據我的經驗，在生產環境中，具有很好的測試代碼，並要求一致的，高性能的應用程序，我選擇完全禁用應用程序池回收。應用程序池回收是一種「功能」，用於消除IIS不穩定的感覺，事實上，通常情況下真正不穩定的是它所託管的應用程序。在我看來，這是一個讓人們部署不到穩定代碼的柺杖。如果它導致你的問題，關閉它，並確保你的應用程序沒有任何內存泄漏等，這可能會導致長期的應用程序不穩定。