Hacker News new | ask | show | jobs
by pranay01 1244 days ago
thanks for the note. Our approach for this benchmark was to use the default configs which each of the logging platforms come with.

This is also because we are not experts in Elastic or Loki, so we won't know the possible impact of tuning configs. To be fair, we also didn't tune SigNoz for this specific data or test scenario and ran it in default settings.

> Graph complaining Elasticsearch using 60% available memory. This is as configured, they could use less with not much impact to performance.

This is something we discussed about, and have added a note in the benchmark blog as well. Pasting again for reference

> For this benchmark for Elasticsearch, we kept the default recommended heap size memory of 50% of available memory (as shown in Elastic docs here). This determines caching capabilities and hence the query performance.

We could have tried to tinker with the different heap sizes ( as a % of total memory) but that would impact query performance and hence we kept the default Elastic recommendation

2 comments

Part of the issue is, Elasticsearch isn't an open-source logging platform--it's a search-oriented database. Effectively using it as an open-source logging platform highly depends on the config vs things optimized only for logs out of the box.

I imagine you'd have similar issues with Postgres or any general purpose datastore without the correct configuration.

I'm not an Elastic expert either, just a developer responsible for a lot of things that can Google pretty good, and I knew those configs seemed off. I've been hearing for years that Beats is preferable over Logstash. I don't even claim to work in the logging space :-)