在本文中，我们测试了 Manticore Search 与 Luwak 在处理 percolate queries 时的性能表现。
介绍
最近，我们 测试了 Manticore Search 与 Elasticsearch 中 percolate queries 的性能 。今天，我们将关注 Luwak——一种基于 Lucene 搜索库的存储查询引擎。
在开发 percolate queries 时，我们研究了现有实现该功能的引擎。Flax（Luwak 的作者）提供的基准测试 在此 显示 Luwak 的性能优于 Elasticsearch，这促使我们将 Manticore 与 Luwak 进行比较。在最初的测试中，我们发现 Luwak 比我们的实现更快，这帮助我们找到了可优化之处，并在某些情况下大幅提升了 Manticore Search 中 percolate queries 的性能。
环境设置
这些基准测试由 Manticore Search 的资深核心开发人员之一，同时也是 Sphinx Search 长期开发者 Stanislav Klinov 负责进行。
latest Manticore Search
Luwak 1.5.0 with the HTTP server branch - https://github.com/tomatolog/luwak/tree/luwak-server
http://github.com/tomatolog/luwak_tests for data and query source and script to post query to daemon via HTTP
http://github.com/Ivinco/stress-tester for running the benchmarks
我们采用了 luwak-server 分支，并将 luwak-1.5.0 分支合并，以同时获得 HTTP 服务器和最新版本的 Luwak。
在之前针对 Elasticsearch 的测试中，我们仅使用了 4 词查询（2 个 MUST 和 2 个 NOT）。现在，我们尝试重现 Luwak（针对 Elasticsearch）进行的 基准测试 条件。我们关注了三种类型的存储查询：
- queries of 7 words, of which 5 are MUST and 2 are NOT
- queries of 120 words, of which 100 are MUST and 20 are NOT
- queries of 20 wildcard words (each made of 4 char suffixes)
我们的目标是使用单个文档和批处理文档执行逆向搜索。percolate queries 由单个搜索工作线程或多个线程触发（以测试并发模式）。
percolate queries 均通过 HTTP API 执行，因此我们将包含 HTTP 服务器的 Luwak 分支与最新稳定代码合并。
测试
Luwak 在不使用批处理时表现略优，但一旦开始批处理文档，Manticore 就会领先。
5x MUST + 2x NOT over 100K stored queries
当我们开始批处理文档时，Luwak 的平均延迟增长得更快。
为了给引擎施加压力，我们增加了多个并发搜索工作线程对其进行轰击。在 100 文档批处理中，虽然 Manticore 出现了性能下降，但 Luwak 依旧略显优势，不过总体仍大约慢 2 倍。
平均延迟也呈现相同的规律：当文档被批处理时，Luwak 的延迟更高。
100x MUST + 20x NOT over 100K stored queries
这种情况对 Luwak 来说冲击较大。
20 wildcards of 4 chars length over 5k stored queries
在测试过程中，我们发现 Manticore 在使用带有通配符的存储查询和批处理文档时存在一个（尚未修复的）性能问题。随着批处理中添加更多文档，其吞吐量下降。与之前的测试相比，Luwak 在非批处理模式下表现较差，但在批处理文档时，其性能略胜 Manticore。
在使用并发工作线程对引擎进行轰击时，并没有显现出明显的优胜者。
在平均延迟方面，当搜索工作者数量较少时，Luwak 在某些情况下表现稍好，但差异并不显著。
结论
对于具有多个非通配符条目的存储查询，Luwak 与 Manticore 平起平坐的唯一情况是非批处理模式。一旦我们开始批量处理文档，Manticore 的吞吐量远远超过 Luwak，平均延迟通常只有 Luwak 一半。
Luwak 的最坏情况是存储查询中有超过一百个非通配符条目。即使在非批处理模式下，Manticore 的速度也快了 3 倍，在处理10个批量文档时最快可达约 20 倍。当文档进行匹配批量处理时，Luwak 的延迟也极高。
对于带有通配符条目的存储查询，没有明显的赢家。在某些情况下，Luwak 的表现略好。我们这边存在一个已知的 bug（Bloom 拒绝过滤器无法如预期工作），这影响了性能。Luwak 的最佳情况是在 20 个文档批处理中，当只有一个搜索工作者运行时，其速度几乎快了 2 倍，但在其他情况下，增益要小得多，或者 Manticore 稍微领先。