Hi Andy I don't want to publish results, since still there are some mistakes in the benchmark. Also this would be controversial, because there are too many parameters to tune and to take into consideration. Nevertheless you can go to the Sensei google group to see the preliminary result for Sensei
At first I was using the benchmark to do the stress testing for Sensei. We needed to identify possible memory leaks and bottlenecks in the new release. After that I've extended the tool to test Solr and Elastic search With many thanks, Volodymyr 2012/4/27 Andy <angelf...@yahoo.com>: > What is the performance of Elasticsearch and SenseiDB in your benchmark? > > > ________________________________ > From: Volodymyr Zhabiuk <vzhab...@gmail.com> > To: solr-user@lucene.apache.org > Sent: Thursday, April 26, 2012 9:50 PM > Subject: Benchmark Solr vs Elastic Search vs Sensei > > Hi Solr users > > I've implemented the project to compare the performance between > Solr, Elastic Search and SenseiDB > https://github.com/vzhabiuk/search-perf > the Solr version 3.5.0 was used. I've used the default configuration, > just enabled json updates and used the following schema > https://github.com/vzhabiuk/search-perf/blob/master/configs/solr/schema.xml. > 2.5 mln documents were put into the index, after > that I've launched the indexing process to add anotherr 500k docs. I > was issuing commits after each 500 doc batch . At the > same time I've launched the concurrent client, that sent the > following type of queries > ((tags:moon-roof%20or%20tags:electric%20or%20tags:highend%20or%20tags:hybrid)%20AND%20(!tags:family%20AND%20!tags:chick%20magnet%20AND%20!tags:soccer%20mom))%20 > OR%20((color:red%20or%20color:green%20or%20color:white%20or%20color:yellow)%20AND%20(!color:gold%20AND%20!color:silver%20AND%20!color:black))%20 > OR%20mileage:[15001%20TO%2017500]%20OR%20mileage:[17501%20TO%20*]%20 > OR%20city:u.s.a.* > &facet=true&facet.field=tags&facet.field=color > The query contains the high level "OR" query, consisting of 2 terms, 2 > ranges and 1 prefix. It is designed to hit ~60-70% of all the docs > Here is the performance result: > #Threads min median mean 75% qps > 1 208.95ms 332.66ms 350.48ms 422.92ms 2.8 > 2 188.68ms 338.09ms 339.22ms 402.15ms 5.9 > 3 151.06ms 326.64ms 336.20ms 418.61ms 8.8 > 4 125.13ms 332.90ms 332.18ms 396.14ms 12.0 > If there is no indexing process on background > The result is as follows for 2,6 mln docs: > #Threads min median mean 75% qps > 1 106.70ms 199.66ms 199.40ms 234.89ms 5.1 > 2 128.61ms 199.12ms 201.81ms 229.89ms 9.9 > 3 110.99ms 197.43ms 203.13ms 232.25ms 14.7 > 4 90.24ms 201.46ms 200.46ms 227.75ms 19.9 > 5 106.14ms 208.75ms 207.69ms 242.88ms 24.0 > 6 103.75ms 208.91ms 211.23ms 238.60ms 28.3 > 7 113.54ms 207.07ms 209.69ms 239.99ms 33.3 > 8 117.32ms 216.38ms 224.74ms 258.74ms 35.5 > I've got three questions so far: > 1. In case of background indexing the latency is almost 2 times > higher, is there any way to overcome this? > 2. How can we tune the Solr to get better results ? > 3. What's in your opinion is the preferred type of queries that I can > use for the benchmark? > > With many thanks, > Volodymyr > > > BTW here is the spec of my machine > RedHat 6.1 64bit > Intel XEON e5620 @2.40 GHz, 8 cores > 63 GB RAM
