# Manticore 2.8.2 vs 3.0 - 2x faster in some tests 正如您可能知道的，最近 Manticore 3.0 [已发布](https://manticoresearch.com/blog/manticore-search-3-0-0-is-now-available/)。 在此基准测试中，我们来看看它是否比 2.8 更好。测试环境如下： - 2016 年的 [Hacker News 精选评论数据集](https://zenodo.org/record/45901/export/xd#.XEqiuc8zaU0) 以 CSV 格式 - 操作系统：Ubuntu 18.04.1 LTS (Bionic Beaver)，内核：4.15.0-47-generic - CPU：Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz，8 核 - 32G 内存 - 硬盘 - Docker 版本 18.09.2 - 索引和 searchd 的基础镜像 - Ubuntu:bionic - [压力测试工具](http://github.com/Ivinco/stress-tester) 用于基准测试 两个版本的 Manticore 配置完全相同： ```bash source full { type = csvpipe csvpipe_command = cat /root/hacker_news_comments.prepared.csv|grep -v line_number csvpipe_attr_uint = story_id csvpipe_attr_timestamp = story_time csvpipe_field = story_text csvpipe_field = story_author csvpipe_attr_uint = comment_id csvpipe_field = comment_text csvpipe_field = comment_author csvpipe_attr_uint = comment_ranking csvpipe_attr_uint = author_comment_count csvpipe_attr_uint = story_comment_count } index full { path = /root/idx_full source = full html_strip = 1 mlock = 1 } searchd { listen = 9306:mysql41 query_log = /root/query.log log = /root/searchd.log pid_file = /root/searchd.pid binlog_path = qcache_max_bytes = 0 } ``` ### 索引 索引耗时 **Manticore 3.0 为 1303 秒**，**Manticore 2.8.2 为 1322 秒**： Manticore 3.0: ```bash indexing index 'full'... collected 11654429 docs, 6198.6 MB creating lookup: 11654.4 Kdocs, 100.0% done creating histograms: 11654.4 Kdocs, 100.0% done sorted 1115.7 Mhits, 100.0% done total 11654429 docs, 6198580642 bytes total 1303.470 sec, 4755444 bytes/sec, 8941.07 docs/sec total 22924 reads, 16.605 sec, 238.4 kb/call avg, 0.7 msec/call avg total 11687 writes, 13.532 sec, 855.1 kb/call avg, 1.1 msec/call avg ``` Manticore 2.8: ```bash indexing index 'full'... collected 11654429 docs, 6198.6 MB sorted 1115.7 Mhits, 100.0% done total 11654429 docs, 6198580642 bytes total 1322.239 sec, 4687939 bytes/sec, 8814.15 docs/sec total 11676 reads, 15.248 sec, 452.6 kb/call avg, 1.3 msec/call avg total 9431 writes, 12.800 sec, 1065.3 kb/call avg, 1.3 msec/call avg ``` 因此，使用此数据集和索引模式 **3.0 的索引速度比 2.8 快约 1.5%**。 ## 性能测试 --- 在测试之前，两个实例都进行了预热。 Manticore 3.0: ```bash total 4.7G drwx------ 2 root root 4.0K May 14 17:41 . drwxr-xr-x 3 root root 4.0K May 14 17:40 .. -rw-r--r-- 1 root root 362M May 14 17:24 idx_full.spa -rw-r--r-- 1 root root 3.1G May 14 17:36 idx_full.spd -rw-r--r-- 1 root root 90M May 14 17:36 idx_full.spe -rw-r--r-- 1 root root 628 May 14 17:36 idx_full.sph -rw-r--r-- 1 root root 29K May 14 17:24 idx_full.sphi -rw-r--r-- 1 root root 6.5M May 14 17:36 idx_full.spi -rw------- 1 root root 0 May 14 17:41 idx_full.spl -rw-r--r-- 1 root root 1.4M May 14 17:24 idx_full.spm -rw-r--r-- 1 root root 1.1G May 14 17:36 idx_full.spp -rw-r--r-- 1 root root 59M May 14 17:24 idx_full.spt ``` Manticore 2.8: ```bash total 4.6G drwx------ 2 root root 4.0K May 16 18:38 . drwxr-xr-x 3 root root 4.0K May 14 17:43 .. -rw-r--r-- 1 root root 362M May 14 17:24 idx_full.spa -rw-r--r-- 1 root root 3.1G May 14 17:36 idx_full.spd -rw-r--r-- 1 root root 27M May 14 17:36 idx_full.spe -rw-r--r-- 1 root root 601 May 14 17:36 idx_full.sph -rw-r--r-- 1 root root 6.3M May 14 17:36 idx_full.spi -rw-r--r-- 1 root root 0 May 14 17:24 idx_full.spk -rw------- 1 root root 0 May 16 18:38 idx_full.spl -rw-r--r-- 1 root root 0 May 14 17:24 idx_full.spm -rw-r--r-- 1 root root 1.1G May 14 17:36 idx_full.spp -rw-r--r-- 1 root root 1 May 14 17:36 idx_full.sps ``` ### 测试 1 - 处理集合中前 1000 个术语所需时间 首先，我们运行一个简单的测试 - 遍历集合中前 1000 个高频术语并为每个术语查找所有文档需要多长时间： 结果是：Manticore 2.8 为 77.61 秒，Manticore 3.0 为 71.79 秒。 ![](./benchmark_manticore28_vs_3/Top-1000-frequent-terms-from-HackerNews-collection-1.png) **因此，在此测试中，Manticore Search 3.0 比上一版本快 8%。** ### 测试 2 - 按组划分的集合中前 1000 个高频术语（前 1-50，前 50-100 等） 现在让我们看看 3.0 在处理不同频率组的术语方面是否更好。下面您可以看到每个组中的一些随机示例：
1至50 50至100 100至150 150至200 200至250 250至300
一 很多 我们的 每个 更少 支付
与 真的 进入 没有 另一个 理解
是 其他 仍然 向下 已经 每个人
300至350 350至400 400至450 450至500 500至550 550至600
搜索 开发人员 创建 兴趣 一般 公司
原因 整个 给定 尝试 模型 办公室
什么都没有 名字 朋友 访问 数量 支付
600至650 650至700 700至750 750至800 800至850 850至900
管理 他们自己 跨越 pg 纸张 核心
相关 市场营销 学到 观点 挑选 高度
去 除非 帖子 风险 强大 交通
900至950 950至1000
想法 不错
界面 年轻
回应 英语
![](./benchmark_manticore28_vs_3/95p-latency-of-top-1000-frequent-terms-from-Hacker-News-collection-by-term-groups-top-1-50-top-50-100-etc.-ms-1.png) ![](./benchmark_manticore28_vs_3/Throughput-of-top-1000-frequent-terms-from-Hacker-News-collection-by-term-groups-top-1-50-top-50-100-etc.-1.png) **Manticore 2.8 在延迟方面平均比 3.0 快 0.4%，并且提供 0.5% 更高的吞吐量。这在误差范围内。** ### 测试 3 - 从集合中按组分解的前 1000 个高频术语 + 组 1-100 中的 1 个术语 让我们看看当您有一个非常频繁的术语和另一个来自不同频率组的较不频繁的术语时它是如何工作的。示例如下：
1-50 50-100 100-150 150-200 200-250 250-300
其他可以 没有 在...之上 关于他的 应该大 s ever
没有是 我的使用 其他为什么 曾经一天 曾经给予 他们让
这里一些 已经知道 s 在哪里 如何确定 已经大 这里e
300-350 350-400 400-450 450-500 500-550 550-600
谁开发者 它书 现在单一 不访问 在解决方案 他们的称为
工作开始 一个ycombinator 从添加 使用站点 知道microsoft 作为主要
在小时 现在价值 也给予 哪个构建 比力量 的早期
600-650 650-700 700-750 750-800 800-850 850-900
知道科学 应该营销 应该孩子 的数字 他们的驱动 谁高度
如果同意 一个分钟 t帖子 时间pg 也极其 可能主题
将相关 有国家 获取帖子 http 教育 也极其 可能主题
900-950 950-1000
任何党派 在特别
仅响应 可能计算机
人们firefox 关于计算机
![](./benchmark_manticore28_vs_3/95-latency-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-ms-1.png) ![](./benchmark_manticore28_vs_3/Throughput-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-1.png) **Manticore 3.0 的吞吐量平均提高了 86.3%，95 百分位延迟降低了 109.5%。** ### 测试 4 - 从集合中按组分解的前 1000 个高频术语 + 从组 1-100 中的 1 个术语，两个术语均用引号括起以形成短语
1-50 50-100 100-150 150-200 200-250 250-300
工作不 你的 我们仍然 自己的 我得到 可以运行
我的 非常 你的工作 使用获得 这里糟糕 然后曾经
但是那 获取共同 我首先 现在每天 上帮助 然后制作
300-350 350-400 400-450 450-500 500-550 550-600
它信息 他们社区 1 关心 什么移动 出快乐 去观看
com 侧 这个服务器 com 位置 在巨大 如何停止 s 写作
他看起来 是 x 时间成为 的尝试 应该来 其他声音
600-650 650-700 700-750 750-800 800-850 850-900
通过 api 不要很快 t 好奇 是多个 的修复 事情绝对
三个中的 使用即将到来 那缺乏 谁 ui 有理解 大多数主题
真的在谈论 制作应用程序 真的环境 将 whoishiring 在昂贵 更多核心
900-950 950-1000
仅仅框架 它抱歉
工作资源 想要好处
他们的资源 s 进一步
![](./benchmark_manticore28_vs_3/95p-latency-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-both-terms-enclosed-in-quotes-to-make-a-phrase-ms-1.png) ![](./benchmark_manticore28_vs_3/Throughput-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-both-terms-enclosed-in-quotes-to-make-a-phrase-1.png) **Manticore v3 在吞吐量方面平均快 5.6%，在 95p 延迟方面平均低 25.1%。** ### 测试 5 - 从 600-750 组中各取 2 个词，在不同并发量下的表现 此测试旨在展示在不同查询并发量下的吞吐量差异。几个随机示例： 查询示例： "talking view", "imagine 15", "curious term" ![](./benchmark_manticore28_vs_3/95p-latency-of-2-terms-each-from-group-600-750-under-different-concurrencies-ms-1.png) ![](./benchmark_manticore28_vs_3/Throughput-of-2-terms-each-from-group-600-750-under-different-concurrencies-1.png) **因此，版本 3 在所有并发量下平均快 18%，95p 延迟平均降低 15%。** ### 测试 6 - 从不同组中取 3-5 个词 现在让我们检查更长查询的性能。 - 从 100-200、400-500、800-900 组中各取 3 个词 - 从 100-200、300-400、500-600、800-900 组中各取 4 个词 - 从 100-200、300-400、500-600、800-900、900-1000 组中各取 5 个词 查询示例：
3 个词 4 个词 5 个词
doing under poor these search awesome background got reason results taken ad
always tried stories working again comment links feel process situation faster bring
job text card google number network function going days browser known salary
![](./benchmark_manticore28_vs_3/95p-latency-of-3-5-terms-1.png) ![](./benchmark_manticore28_vs_3/Throughput-of-3-5-terms-1.png) **版本 3 再次胜出：吞吐量提高 104%，95p 延迟降低 113%。** ### 测试 7：从 300-600 组中取 3 个 AND 词和从 300-400 组中取 1 个 NOT 词 现在我们在 3 个 AND 词中添加一个 NOT 词。 ![](./benchmark_manticore28_vs_3/95p-latency-of-5-terms-from-groups-100-200-300-400-500-600-800-900-900-1000.png) ![](./benchmark_manticore28_vs_3/Throughput-of-5-terms-from-groups-100-200-300-400-500-600-800-900-900-1000.png) **v3 的吞吐量提高 33.3%，95p 延迟降低 32%。** # 结论 **新版本在所有测试中表现出显著更高的性能，除了测试 #2，但那里的差异在误差范围内（0.4-0.5%）。** 该测试完全使用 Docker 容器化，并且 [在我们的 GitHub 上开源](https://github.com/manticoresoftware/benchmarks/tree/53aa3b1c7f905319e854c537baf8524c6b919404/2vs3)。详细结果可以在 [此处](https://docs.google.com/spreadsheets/d/1zkoN6XwFig5LinLX9kxbRVVfr0kcnKaX992DPEVzMtU/edit?usp=sharing) 找到。如果您在自己的硬件上运行相同的测试或通过添加更多测试用例来贡献，我们将不胜感激，并请告知我们结果。 如果您发现任何问题或不准确之处，请随时告知我们。 感谢阅读！