我是Solr的“新手”（使用8.7版本）。我正在尝试对解决方案进行基准测试，我的测试之一是将相同的查询多次发送到同一集合上的同一个solr节点，以确保响应时间的相关性，并估计我们可以观察到的潜在差异。
我的问题是有时候第一次发送查询的响应时间会比下面的时间长。下面是一个例子，同一个查询发送10次的响应时间（毫秒）：31380，405，423，412，364，381，383，378，369，266（这个查询使用了sort和fq，with {！cache=false}）。一开始我以为可能是主机解析的问题，但是在将目标主机更改为机器的IP地址后，我仍然有这个问题。我的机器上没有其他进程在运行，它是专门用于solr基准测试的，所以在我看来，这不是CPU或RAM的问题。我使用的SolrCloud有2个节点，但我发送请求的集合只有1个片段和1个副本，所以我不认为这是由于节点之间的通信...
推荐我尝试的东西：
- 在solrconfig中禁用缓存（filterCache、queryResultCache和documentCache，甚至是默认情况下名为“perSegFilter”的自定义缓存..），首先添加enabled=“false”，然后注解掉块（然后重新加载集合等...甚至重新启动集群），我不断检查solr缓存指标，看看它们是否被使用;
- 在查询中尽可能使用{！cache=false};
- 禁用冷搜索器。
在Solr文档和论坛上搜索了很长时间后，我已经没有什么想法了。如果有人遇到了这个问题，或者有人有一个想法或解释它是如何工作的（也许它不是问题），这将对我有很大的帮助。
感谢您抽出宝贵时间
1条答案
按热度按时间a0x5cqrl1#
更新：你看到的时间足够长，CPU频率/CPU缓存/ JVM“预热”应该是第一次查询总时间的一小部分。这应该在一秒内稳定下来。我不认为这个答案解释了31秒，0.4秒等。也许有一些应用程序级的缓存，除非有一些巨大的I/O瓶颈和磁盘缓存解释它。
TL：DR：这个答案可能无法解释大多数的慢首跑效应。如果我们说的是30毫秒，那么0.4毫秒，它可能会解释，但我们不是。
对于一般的基准测试，在第一次测试速度较慢的情况下，“热身”效果是非常普遍的。
您正在阻止它缓存查询 * 结果 *，因此必须重新计算它，但如果在同一CPU上使用相同的数据，计算速度会更快，这是完全正常的。
首先，CPU将需要一些时间来决定从空闲切换到最大turbo时钟频率（特别是如果它比英特尔Skylake早，后者引入了较低的延迟频率控制）。
第二，有许多形式的缓存可以加快另一次计算的速度，例如，JVM本身可能在第一次运行时已经进行了概要分析和JIT编译，因此它可以只运行本机代码。第二，内存可能已经分配（由JVM）并且已经发生页面错误，不需要从OS分配。分支预测将已经学习了一些分支模式，如果查询之间没有延迟，CPU没有时间进入真正的深度睡眠（这将刷新缓存并关闭缓存，包括分支预测器）。
另外，在第一次查询时需要来自磁盘的任何数据现在应该在RAM中处于热状态，这使得操作系统可以更快地处理打开/读取系统调用。除非您要重新启动整个虚拟机或执行操作系统级别的
drop_caches（如果您希望对冷状态进行基准测试）。（除非正常情况下查询的工作集比RAM大，否则可能不现实。）另请参阅Idiomatic way of performance evaluation?了解各种CPU /操作系统
（注意：我对Solr一无所知，我只是从鼠标悬停的标签上看到的。我在这里是为了benchmarking/性能/cpu架构问题）。