这个问题的标题代表了我主要关心的问题，但是如果您继续阅读问题部分之外的内容，您会发现一些关于我们设置的背景......这可能相关/有用，也可能不相关。
问题
我们正在使用Gatling对我们的应用程序进行压力测试，并在单台机器上运行 Gatling 场景。我们发现我们的应用程序能够应对压力工具产生的高负载；但是，它无法应对来自真实用户的相对较低的负载。
我的问题是：当从单台机器/操作系统向应用程序发出并发请求时，与来自多台机器的并发请求（即使用他们的网络浏览器的普通用户）相比，会发生什么样的操作系统/网络级别优化或简化？
背景
我们有一个通过 AJP 位于 Apache 后面的 Tomcat 应用程序，它本身通过端口 80 位于 Citrix Netscaler 后面（我们还计划将 Apache 排除在外，但这是另一回事..）。
我们的应用程序在相对较低的负载下（在 apache 和 tomcat 之间建立了 CLOSE_WAIT 连接）一直处于停止状态，我们正在对其进行负载测试以解决问题。在我们的 SQLServer 实例中发生的死锁非常频繁地出现，因此我们决定从那里开始。为了复制问题并随后测试我们的修复，我们使用单台机器使用 Gatling 生成负载。
刚开始时，我们能够通过使用该工具可靠地复制死锁。在我们进行一些优化之后，死锁消失了，CLOSE_WAIT 连接也消失了。然后，我们将应用程序推到我们非常满意的负载，并且它运行时没有任何重大故障。
不幸的是，当修复应用到生产系统时，我们仍然看到相同的原始行为。这让我想知道压力工具生成的负载是否不能很好地代表现实世界中实际发生的情况，因为它源自单一来源，而不是分布在互联网上的许多不同客户端。
单个负载生成器可能会比不同的客户端做得更好。例如，更好地使用 Keepalives。这使得通过更少的连接获得更多的请求。
如果涉及轮询 DNS，它将倾向于只命中一个 DNS 目的地，而不是将负载分散到所有目的地。一些负载均衡器根据客户端 IP 做出粘性决策，在这种情况下这将是静态的。
您的负载生成器可能有一个受限的执行池（例如，200 个“用户”），因此响应延迟会导致用户速度变慢，而在现实世界中，您有大量不耐心等待的用户其他用户完成。
如果没有看到您的 Gatling 测试场景，就很难留下任何东西。只是一个“盲目的镜头”：您的 Gatling 测试不能准确地代表真实用户，即
DNS缓存。由于 IP 地址在 JVM 级别缓存 DNS 名称，Gatling 可能只命中一个 IP 地址。根据加特林常见问题解答：
AJAX 请求。Gatling 不执行客户端 JavaScript，因此如果您的应用程序是基于 XMLHTTP Requests 构建的，则 Gatling 访问页面时不会触发它们。如果您的应用程序使用某种形式的 AJAX，您将需要手动处理它们
所以我建议参考How To Make JMeter Behave More Like A Real Browser并实现等效的 Gatling 设置，就好像负载测试不代表现实生活中的负载一样，运行这样的测试没有多大意义。