當您使用單台機器產生負載/壓力時，會發生什麼樣的“精簡”？
這個問題的標題代表了我主要關心的問題，但是如果您繼續閱讀問題部分之外的內容，您會發現一些關於我們設置的背景……這可能相關/有用，也可能不相關。
問題
我們正在使用Gatling對我們的應用程序進行壓力測試，並在單台機器上執行 Gatling 場景。我們發現我們的應用程序能夠應對壓力工具產生的高負載；但是，它無法應對來自真實使用者的相對較低的負載。
我的問題是：當從單台機器/作業系統向應用程序發出並發請求時，與來自多台機器的並發請求（即使用 Web 瀏覽器的普通使用者）相比，會發生什麼樣的作業系統/網路級別優化或簡化？
背景
我們有一個通過 AJP 位於 Apache 後面的 Tomcat 應用程序，它本身通過埠 80 位於 Citrix Netscaler 後面（我們還計劃將 Apache 排除在外，但這是另一回事..）。
我們的應用程序在相對較低的負載下（在 apache 和 tomcat 之間建立了 CLOSE_WAIT 連接）一直處於停止狀態，我們正在對其進行負載測試以解決問題。在我們的 SQLServer 實例中發生的死鎖非常頻繁地出現，因此我們決定從那裡開始。為了複製問題並隨後測試我們的修復，我們使用單台機器使用 Gatling 生成負載。
剛開始時，我們能夠通過使用該工具可靠地複制死鎖。在我們進行一些優化之後，死鎖消失了，CLOSE_WAIT 連接也消失了。然後，我們將應用程序推到我們非常滿意的負載，並且它執行時沒有任何重大故障。
不幸的是，當修復應用到生產系統時，我們仍然看到相同的原始行為。這讓我想知道壓力工俱生成的負載是否不能很好地代表現實世界中實際發生的情況，因為它源自單一來源，而不是分佈在網際網路上的許多不同客戶端。
單個負載生成器可能會比不同的客戶端做得更好。例如，更好地使用 Keepalives。這使得通過更少的連接獲得更多的請求。
如果涉及輪詢 DNS，它將傾向於只命中一個 DNS 目的地，而不是將負載分散到所有目的地。一些負載均衡器根據客戶端 IP 做出粘性決策，在這種情況下這將是靜態的。
您的負載生成器可能有一個受限的執行池（例如，200 個“使用者”），因此響應延遲會導致使用者速度變慢，而在現實世界中，您有大量不耐心等待的使用者其他使用者完成。