blog-post

Manticore 2.8.2 vs 3.0 - 2x faster in some tests

As you probably know recently a new release of Manticore 3.0 was released.

In this benchmark let’s see if it’s any better than 2.8. The test environment was as follows:

  • Hacker News curated comments dataset of 2016 in CSV format
  • OS: Ubuntu 18.04.1 LTS (Bionic Beaver), kernel: 4.15.0-47-generic
  • CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 8 cores
  • 32G RAM
  • HDD
  • Docker version 18.09.2
  • Base image for indexing and searchd - Ubuntu:bionic
  • stress-tester for benchmarking

The config is identical for the both versions of Manticore:

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
}

Indexation

Indexation took 1303 seconds for Manticore 3.0 and 1322 seconds for Manticore 2.8.2:

Manticore 3.0:

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 <b>1303.470</b> 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:

indexing index 'full'...
collected 11654429 docs, 6198.6 MB
sorted 1115.7 Mhits, 100.0% done
total 11654429 docs, 6198580642 bytes
total <b>1322.239</b> 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

So with this data set and index schema indexation in 3.0 is faster than in 2.8 by ~1,5%.

Performance tests


The both instances were warmed up before testing.

Manticore 3.0:

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:

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

Test 1 - time to process top 1000 terms from the collection

First of all let’s just run a simple test - how long it takes to go through top 1000 frequent terms of the collection and find all documents for each:

The results are: 77.61 seconds for Manticore 2.8 and 71.79 seconds for Manticore 3.0.

So in this test Manticore Search 3.0 is faster than the previous version by 8%.

Test 2 - top 1000 frequent terms from the collection broken down by groups (top 1-50, top 50-100 etc.)

Now let’s see if 3.0 is better in terms of processing terms from different frequencies groups. Below you can find just few random examples from each of the groups:

1-50 50-100 100-150 150-200 200-250 250-300
one much our every less pay
with really into without another understand
was other still down already everyone
300-350 350-400 400-450 450-500 500-550 550-600
search developers create interest general co
reason whole given tried model office
nothing name friends access amount paid
600-650 650-700 700-750 750-800 800-850 850-900
management themselves across pg paper core
related marketing learned opinion pick highly
goes unless posts risk strong traffic
900-950 950-1000
thoughts decent
interface young
response english


Manticore 2.8 is in average faster than 3.0 by 0,4% for latency and provides 0.5% higher throughput. This is within the error range.

Test 3 - top 1000 frequent terms from the collection broken down by groups + 1 term from group 1-100

Let’s see how it works when you have one very frequent term and another less frequent from different frequency groups. The examples are:

1-50 50-100 100-150 150-200 200-250 250-300
other can the no on over about his should big s ever
no are my use other why had day had give them let
here some been know s where how sure been big here e
300-350 350-400 400-450 450-500 500-550 550-600
who developer it book now single not access at solution their called
work started an ycombinator from add use sites know microsoft as mostly
at hours now value also given which built than power of early
600-650 650-700 700-750 750-800 800-850 850-900
know science should marketing should kids the numbers their drive who highly
if agree an minutes t posts time pg there pick has opportunity
would related has country get posts http education also extremely could topic
900-950 950-1000
any party on particularly
only response could computers
people firefox about computers


Manticore 3.0 shows in average 86.3% higher throughput and 109,5% lower 95p latency.

Test 4 - top 1000 frequent terms from the collection broken down by groups + 1 term from group 1-100, both terms enclosed in quotes to make a phrase

1-50 50-100 100-150 150-200 200-250 250-300
"work not" "you their" "we still" "s own" "me getting" "could run"
"my for" "the very" "your job" "use got" "here bad" "then ever"
"but that" "get com" "i first" "now day" "up help" "then making"
300-350 350-400 400-450 450-500 500-550 550-600
"it information" "them community" "1 care" "what mobile" "out happy" "to watch"
"com side" "this server" "com position" "at huge" "how stop" "s written"
"he looks" "was x" "time become" "the tried" "should comes" "other sounds"
600-650 650-700 700-750 750-800 800-850 850-900
"by api" "don soon" "t curious" "was multiple" "of fix" "things absolutely"
"of three" "use coming" "that lack" "who ui" "ve understanding" "most topic"
"really talking" "make applications" "really environment" "will whoishiring" "at expensive" "more core"
900-950 950-1000
"just framework" "it sorry"
"work resources" "want benefit"
"their resources" "s further"


Manticore v3 is in average 5.6% faster for throughput and 25.1% lower for 95p latency.

Test 5 - 2 terms each from group 600-750 under different concurrencies

This test aims to show the difference in throughput under different query concurrencies. Few random examples:

Query examples: “talking view”, “imagine 15”, “curious term”


So version 3 is faster under all the concurrencies by average 18% with avg 95p latency lower by 15%.

Тest 6 - 3-5 terms from different groups

Let’s now check performance with longer queries.

  • 3 terms from groups 100-200 400-500 800-900
  • 4 terms from groups 100-200 300-400 500-600 800-900
  • 5 terms from groups 100-200 300-400 500-600 800-900 900-1000

Query examples:

3 terms 4 terms 5 terms
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


Version 3 wins again: throughput - 104% higher with 113% lower 95p latency.

TEST 7: 3 AND terms from groups 300-600 and 1 NOT from 300-400

Let’s now add one NOT term to 3 AND.


throughput in v3 - 33.3% higher, 95p latency - 32% lower.

Conclusions

The new version demonstrates significantly higher performance in all the tests except for the test #2, but the difference there is within the error range (0.4-0.5%).

The test is fully dockerized and open sourced in our github. The detailed results can be found here We’ll appreciate if you run the same tests on your hardware or contibute by adding more tests to the suite and let us know the results.
If you find any issue or inaccuracy don’t hesitate to let us know.

Thank you for reading!

Install Manticore Search

Install Manticore Search