I'm not a fan of competitors creating benchmarks like this as when faced with any tuning decision, they will usually pick the one the makes their competitors slower. But anyway lets take a look at how they tuned Elasticsearch.
Disclaimer I used to work at Elastic!
- Used Logstash instead of Beats for simple task of reading syslog json data.
Beats (https://www.elastic.co/guide/en/beats/filebeat/current/fileb...) would have performed better especially around resource usage.
- Set very low Logstash heap of 256mb
https://github.com/SigNoz/logs-benchmark/blob/0b2451e6108d8f...
- Added grok processor https://github.com/SigNoz/logs-benchmark/blob/0b2451e6108d8f...
Dissect is faster here
- No index template configuration
This would cause higher disk usage than needed due to duplicate mappings. Again a Logstash vs Beats thing. For this test more primary shards and a larger refresh interval would also improve things.
- Graph complaining Elasticsearch using 60% available memory.
This is as configured, they could use less with not much impact to performance.
- Document counts do not match..
This is probably due to using syslog with random generated data vs creating a test dataset on disk and reading the same data into all platforms.
- Aggregation queries were not provided in repo https://github.com/SigNoz/logs-benchmark so cannot validate.
I'm actually surprised Elastic did so well in this benchmark given the misconfiguration.
Disclaimer I used to work at Elastic!
- Used Logstash instead of Beats for simple task of reading syslog json data. Beats (https://www.elastic.co/guide/en/beats/filebeat/current/fileb...) would have performed better especially around resource usage.
- Set very low Logstash heap of 256mb https://github.com/SigNoz/logs-benchmark/blob/0b2451e6108d8f...
- Added grok processor https://github.com/SigNoz/logs-benchmark/blob/0b2451e6108d8f... Dissect is faster here
- No index template configuration This would cause higher disk usage than needed due to duplicate mappings. Again a Logstash vs Beats thing. For this test more primary shards and a larger refresh interval would also improve things.
- Graph complaining Elasticsearch using 60% available memory. This is as configured, they could use less with not much impact to performance.
- Document counts do not match.. This is probably due to using syslog with random generated data vs creating a test dataset on disk and reading the same data into all platforms.
- Aggregation queries were not provided in repo https://github.com/SigNoz/logs-benchmark so cannot validate.
I'm actually surprised Elastic did so well in this benchmark given the misconfiguration.