Php 查找elasticsearch响应较慢的原因

我在电子商务网站上使用elasticsearch已经有相当一段时间了——不仅用于搜索，还用于检索产品数据（/index/type/{id}），以避免SQL查询

通常情况下，这非常有效，大多数请求都在1到3毫秒之间得到响应。但也有一些请求需要100ms-250ms的时间——仅针对像/index/type/{id}这样的GET请求，没有进行实际搜索，通常需要1-2ms的时间。在我看来，如果这样的响应时间超过100毫秒，那么一定是出了什么问题，因为服务器有很多RAM&一个快速的6核CPU，数据存储在非常快的SSD上，只有15万个条目（在Elasticsearch中约300 MB），而且几乎没有负载。Elasticsearch有5GB的RAM，并且有足够的备用RAM供Lucene随时缓存所有条目。请求通过带有专用交换机的本地网络发出。索引只有一个碎片，我正在运行Elasticsearch 2.3

我正在用PHP处理请求。我已经尝试过使用Nginx作为Elasticsearch的反向代理，但这并没有解决任何问题——它在使用Nginx和不使用Nginx的情况下都会发生

编辑：慢速请求发生率约为1%（相对于请求总数）。我也可以通过在PHP中向Elasticsearch中的/index/type/{id}发出1000个请求来复制它-总是1%会非常慢，即使使用相同的id，比如/index/type/55（只要id存在）。这也意味着没有“缓存效应”——在第一次请求后，Elasticsearch应该将数据“准备就绪”，但无论我请求什么ID，或者如果我反复请求相同的ID，缓慢请求的数量都是相同的

Edit2：我已经用Marvel&Kibana查看了我节点的统计数据，没有任何迹象表明速度变慢：使用了20-40%的JVM堆内存，几乎没有延迟（0.1ms到0.5ms之间）。它确认有足够多的资源，我看不到任何缓慢请求的原因的关联或提示

经过大量测试：

以下是我确定的测试结果：

• Elasticsearch的响应越大，慢请求发生的可能性就越大。许多小的反应不比一个大的反应慢得多
• 用简单的GET请求轰炸Elasticsearch可以降低并行运行更多请求时响应缓慢的可能性
• 当一次又一次地对一个关键字进行简单搜索时，Elasticsearch会在响应中告诉我它“花了”2-3毫秒，即使在我的应用程序收到一个响应之前需要200毫秒。但这里也有：反应越大，反应慢的几率越高。当我运行请求循环时，1KB的响应从来都不慢，2.5KB只是有点慢（30ms），在极少数情况下，10KB的响应总是有高达200ms的慢请求的1%

我已经考虑到这可能是一个网络“问题”，特别是当Elasticsearch认为它很快，即使它很慢。但这将是一个奇怪的根本原因，因为我的设置是如此标准（Debian Jessie）。此外，keep-alive连接和TCP_节点延迟也无法改善此问题

---

有人知道如何找到根本原因，以及可能发生的情况吗？

我终于找到了反应缓慢的原因：是网络驱动程序，甚至是网卡上的硬件实现

当从节点本身运行测试时，缓慢的响应消失了，我还注意到较旧的服务器（使用了8年，而只有2年的较新服务器）在运行测试时没有缓慢的响应，这表明请求服务器出现故障，而不是响应的ES服务器，但它也表明网络本身是好的，因为只有“新”服务器有这个问题

我深入TCP/网络设置的兔子洞，找到了ethtool，它显示了网络配置并允许更改它。我了解到有一种称为“卸载”的方法，将大量网络操作卸载到网卡上（特别是将请求和响应拆分为段），并尝试使用以下命令禁用所有卸载：

ethtool -K eth1 tx off rx off sg off tso off ufo off gso off gro off lro off rxvlan off txvlan off rxhash off

之后，我的request-1000-idential-searches-from-ES的速度和预期的一样快——不再有缓慢的请求。我的网卡（运行e1000e驱动程序的SuperMicro X9SRL-F上的Intel®82574L双端口GbE LAN）似乎在硬件中起到了某种作用，减慢响应速度，或阻止响应速度，或其他任何情况。较旧的服务器正在运行tg3驱动程序—在这些服务器上启用了卸载（根据ethtool），但不会导致这些延迟响应。禁用卸载对CPU负载没有明显的影响，这在任何现代CPU中都是意料之中的

有了新的设置，我能够将由于Elasticsearch响应缓慢而导致的慢速页面数降低到0.07%，而之前的页面数约为1%。我还注意到，使用Nginx作为Elasticsearch的反向代理会导致一些缓慢的响应，尽管它们并不多——通常每15万个响应中有3-5个响应超过50毫秒。没有Nginx，通过直接查询Elasticsearch，我现在无法再复制任何缓慢的请求，即使是大规模的

更新日期2017年11月

---

更新到Debian Stretch并使用内核4.9运行服务器后，所有剩余的“慢速请求”都消失了。因此，这个问题似乎至少部分根源于较旧的linux内核。

这可能完全无关，但它是。。。我使用AWS CloudSearch、RDS、EC2/BeanStalk和ElastiCache，最近我在各种DNS查找中看到了200毫秒的延迟。您的100-200毫秒延迟是从哪里看到的？通过应用程序或直接端点到AWS搜索服务的完整浏览器往返？我使用自己的服务器（托管）-测量