|Search Latency (ms, 4 concurrent users)||3||72||24|
|Maximum Throughput (QPS)||1424||71||20|
|Maximum Concurrent Users (latency<1s)< /td>||1400||6||233|
|Indexing Speed (million docs/day)||536||562||0.95|
The benchmark was performed with a English Wikipedia dump (5,677,776 documents, 63.9 GB) with a single instance of the software on identical hardware and operation system, directly on the search server, excluding HTTP server and Internet routing, which is highly dependent on customer connection and location. See detailed benchmarks (results, source code, test data sets) comparing SeekStorm with Lucene*, which both Solr* and Elasticsearch* are based on.
Concurrent users vs. rate limit
Why is the much higher concurrency important if the search-as-a-service plans comes with a rate limit anyway? Only because the software is much more efficient, and allows serving many more users on the same hardware, we can provide you the service at a much lower cost than if you would operate your own search server with the benchmarked open-source software. Additionally, you fully benefit with every single query from the low latency that comes with the high concurrency.
(*) All mentioned trademarks and proper names belong to their respective owners, and do not imply any affiliation or any other kind of an alliance with their respective owners.