這個問題的標題代表了我主要關心的問題，但如果您繼續閱讀問題部分，您會發現一些有關我們設置的背景…這可能相關/有用，也可能不相關/有用。
問題
我們正在使用以下方式對我們的應用程式進行壓力測試加特林，並且正在運行加特林場景單身的機器。我們發現我們的應用程式能夠應對壓力工具產生的高負載；然而，它無法應對真實用戶相對較低的負載。
我的問題是：當從單一機器/作業系統向應用程式發出並發請求時，與來自多台機器（即使用Web 瀏覽器的普通用戶）發出並發請求時，會發生什麼樣的作業系統/網絡等級優化或簡化？
背景
我們有一個 Tomcat 應用程式透過 AJP 位於 Apache 後面，該應用程式本身透過連接埠 80 位於 Citrix Netscaler 後面（我們還計劃將 Apache 排除在外，但那是另一回事...）。
我們的應用程式在相對較低的負載（apache 和 tomcat 之間建立 CLOSE_WAIT 連線）下逐漸停止，我們正在對其進行負載測試以解決問題。我們的 SQLServer 實例中發生的死鎖非常頻繁，因此我們決定從這裡開始。為了重現問題並隨後測試我們的修復，我們使用一台機器透過 Ga特林 產生負載。
當我們剛開始時，我們能夠使用該工具可靠地複製死鎖。在我們進行一些優化之後，死鎖消失了，CLOSE_WAIT 連線也消失了。然後，我們將應用程式推至我們非常滿意的負載，並且它運行時沒有出現任何重大問題。
不幸的是，當修復應用於生產系統時，我們仍然看到相同的原始行為。這讓我想知道壓力工具產生的負載是否不能很好地代表現實世界中實際發生的情況，由於它源自單一來源，而不是分佈在互聯網上的許多不同客戶端。
答案1
單一負載產生器可能比不同的客戶端在連接池方面做得更好；例如，更好地使用 Keepalives。這使得透過更少的連接來處理更多的請求。
如果涉及循環 DNS，它將傾向於僅命中其中一個 DNS 目標，而不是將負載分散到所有這些目標。一些負載平衡器會根據客戶端 IP 做出黏性決策，在這種情況下客戶端 IP 是靜態的。
您的負載產生器可能有一個受限的執行池（例如，200 個「用戶」），因此回應延遲會導致用戶速度變慢，這與現實世界相反，在現實世界中，您有大量不耐心等待的用戶其他用戶來完成。
答案2
如果沒有看到您的加特林測試場景，就很難留下任何東西。只是“盲目射擊”：您的加特林測試不能準確代表真實用戶，即
- 真正的瀏覽器下載嵌入到頁面中的外部資源，即圖像、腳本和樣式，並使用並發線程池來完成此操作。如果您的加特林測試遺失推斷Html資源方法可能會出現這樣的情況：來自加特林的負載比坐在真實瀏覽器後面的真實用戶所執行的負載要少得多
DNS 快取。由於 JVM 層級的 DNS 名稱快取背後的 IP 位址，Gattle 可能只會命中一個 IP 位址。按照加特林常見問題解答：
基本上，Gattle/JVM 的 DNS 快取必須進行調整。解決辦法是
-Dsun.net.inetaddr.ttl=0在命令列中新增。AJAX 請求。加特林不執行客戶端 JavaScript，因此如果您的應用程式是基於 XMLHTTP 請求構建的，那麼當加特林訪問頁面時它們不會被觸發。如果您的應用程式使用某種形式的 AJAX，您將需要手動處理它們
所以我建議參考如何讓 JMeter 的行為更像真正的瀏覽器並實現等效的加特林設置，就好像負載測試並不代表現實生活中的負載一樣，運行這樣的測試沒有多大意義。