在本文中，我们测试了Manticore搜索和Luwak中感知查询的性能。
引言
最近我们 测试了Manticore搜索和Elasticsearch中感知查询的性能 。今天我们将研究基于Lucene搜索库的存储查询引擎Luwak。
在开发感知查询时，我们查看了实现此功能的现有引擎。Flax（Luwak的作者）提供的基准测试 在此处 促使我们将Manticore与Luwak进行对比，因为它的性能优于Elasticsearch。在最初的测试中，我们发现Luwak比我们的实现更快，这帮助我们识别了可以优化的地方，并大大提高了Manticore搜索中感知查询的性能。
设置
这些基准测试由Manticore搜索的高级核心开发人员之一，同时也是Sphinx搜索的长期开发人员Stanislav Klinov进行。
最新的Manticore搜索
带有HTTP服务器分支的Luwak 1.5.0 - https://github.com/tomatolog/luwak/tree/luwak-server
http://github.com/tomatolog/luwak_tests 用于数据和查询源以及通过HTTP向守护进程发送查询的脚本
我们取了luwak-server分支并合并了luwak-1.5.0分支，以同时拥有HTTP服务器和最新版本的Luwak。
在之前与Elasticsearch的测试中，我们仅使用了4个单词的查询（2个MUST和2个NOT）。现在我们尝试复制Luwak进行的 基准测试 （针对Elasticsearch）的条件。我们关注了3种类型的存储查询：
7个单词的查询，其中5个是MUST，2个是NOT
120个单词的查询，其中100个是MUST，20个是NOT
20个通配符单词（每个由4个字符后缀组成）
我们的目标是使用单个和批处理文档执行反向搜索。感知查询由单个搜索工作者或多个工作者执行（以测试并发模式）。
感知查询使用HTTP API执行，因此我们将包含HTTP服务器的Luwak分支与最新稳定代码合并。
测试
当不使用批处理时，Luwak的性能稍好，但一旦开始批处理文档，Manticore就占据了优势。
100K存储查询中的5x MUST + 2x NOT
随着文档批处理的开始，平均延迟在Luwak上增长得更快。
为了给引擎施加压力，我们添加了多个并发搜索工作者对引擎进行攻击。在100个文档批处理时，Luwak的性能稍好，而Manticore变慢，但仍然大约慢2倍。平均延迟遵循相同的模式：当文档批处理时，Luwak的延迟更高。
100K存储查询中的100x MUST + 20x NOT
这种情况对Luwak造成了严重打击。
5K存储查询中的20个4个字符长度的通配符
在测试过程中，我们发现Manticore在使用带通配符的存储查询和批处理文档时存在性能问题（尚未修复）。随着批处理文档数量的增加，吞吐量下降。与之前的测试相反，Luwak在非批处理模式下表现不佳，但随着文档批处理，它略微优于Manticore。
当使用并发工作者轰炸引擎时，没有明确的赢家。
在平均延迟方面，当搜索工作者数量较少时，Luwak在某些情况下表现稍好，但差异并不显著。
结论
对于具有多个非通配符术语的存储查询，Luwak与Manticore相当的唯一情况是在非批处理模式下。一旦我们对文档进行批处理，Manticore在吞吐量上大大超过Luwak，平均延迟通常是Luwak的一半。
Luwak的最坏情况是存储查询中有超过一百个非通配符术语。即使在非批处理模式下，Manticore的速度也超过3倍，在10个批处理文档的情况下速度可达约20倍。当文档被批处理以进行匹配时，Luwak的延迟也极高。
对于具有通配符术语的存储查询，没有明确的赢家。Luwak在某些情况下表现稍好。我们这边有一个已知的bug（Bloom拒绝过滤器未按预期工作），这影响了性能。Luwak的最佳情况是在20个文档批处理时，只有一个搜索工作者在运行，此时它的速度几乎是2倍，但在其他情况下，收益要小得多，或者Manticore稍微领先。