我有一个在 Jetty 下运行的 Spring MVC 应用程序。它使用 Ektorp 连接到同一主机上的 CouchDB 实例。在这种情况下，一旦 Web API 请求进入 Jetty，我就没有任何代码可以连接到不在 Jetty 实例运行的本地主机上的任何东西。这是以后很重要的一点。
我在 Jetty 中有调试语句来向我展示我的应用程序的各种组件的性能，包括查询我的 CouchDB 数据库的性能。
场景 1：当我从 localhost 发起 API 请求时，即我使用 Chrome 访问http://localhost:8080/时，我的调试语句表明 CouchDB 性能为 X。 场景 2：当我发起完全相同的 API 请求时远程主机，即我使用 Chrome 访问 http://:8080/，我的调试语句表明 CouchDB 性能为 4X。
看起来有些东西导致在场景 2 中与 CouchDB 的连接比场景 1 慢得多。这似乎没有意义，因为一旦请求进入我的应用程序，无论它来自哪里，我都不会在应用程序中有任何代码根据初始 API 请求的来源以不同的方式建立与 CouchDB 的连接。事实上，我没有任何东西可以基于任何东西以不同的方式建立与 CouchDB 的连接。它总是相同的连接（从应用程序的角度来看），并且我已经能够在场景 1 和 2 之间通过 Jetty 重新启动 100% 的时间重现此问题，因此它似乎也与缓存无关。
我已经对 StdCouchDbConnector 和 StdHttpClient 进行了相当深入的研究，试图弄清楚这两种情况是否有任何不同，但看不出有什么不同。
我在 StdHttpClient 中的 executeRequest(HttpUriRequest request, boolean useBackend) 调用周围添加了计时器，以确认这是延迟发生的地方，而且确实是这样。场景 1 和场景 2 的时间差在 client.execute() 上是几倍的，它基本上使用 Apache HttpClient 连接到 CouchDB。
我也一直尝试在 StdHttpClient 中使用“后端”HttpClient，只是为了将 Apache HTTP 缓存排除在外，我得到了与场景 1 和 2 相同的结果。
以前有没有人遇到过这个问题，或者有没有人知道这里可能发生了什么？我一直到 org.apache.http.impl.client.DefaultRequestDirectory 尝试查看场景 1 和 2 之间是否有任何不同，但找不到任何东西......
一些附加说明：
一个。我目前受限于 EC2 中的 Windows 环境，因此实例是虚拟化的。湾。当底层实例未虚拟化时，场景 1 和 2 给出相同的响应时间。但是请看 - 我必须在 AWS 上。C。在第三种情况下，我还可以重现与场景 2 类似的 4 倍慢的性能：我不是使用 Chrome 制作 localhost:8080/，而是使用 Postman，它是一个 Chrome 应用程序。使用 Jetty 实例本身的 Postman，我可以重现慢 4 倍的时间。
我在 c 中看到的唯一区别。上面是 Chrome 的开发者工具中的请求标头指示 [::1]:8080 的远程地址。我没有办法通过 Postman 设置它，所以我不知道这是否是差异制造者。如果是的话，首先我不明白为什么。其次，我不确定我能做些什么，因为我无法控制每个客户端将如何连接到我的 API。
欢迎所有的理论、问题和想法。提前致谢！