# Reasoning behind Geonames Rally Design
**URL:** https://discuss.elastic.co/t/reasoning-behind-geonames-rally-design/333271
**Category:** Elasticsearch
**Tags:** rally
**Created:** [May 12, 2023, 9:03am UTC](https://discuss.elastic.co/t/reasoning-behind-geonames-rally-design/333271 "2023-05-12T09:03:20Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@lquenti](https://discuss.elastic.co/u/lquenti)
#### Post date: [May 12, 2023, 9:03am UTC](https://discuss.elastic.co/t/reasoning-behind-geonames-rally-design/333271/1 "2023-05-12T09:03:20Z")
Hi,
I am currently evaluating Elasticsearch for a HPC related data lake infrastructure. For that, we are currently using [rally](https://esrally.readthedocs.io/en/stable/) benchmarker, especially with the [geonames](https://github.com/elastic/rally-tracks/tree/master/geonames) and [nyc taxis](https://github.com/elastic/rally-tracks/tree/master/nyc_taxis).
Since our HPC environment is batch job dominated, we care more about throughput scalability than the actual latency as it is very unlikely to become a bottleneck in computing-oriented jobs.
While analyzing [the geonames schedule](https://github.com/elastic/rally-tracks/blob/master/geonames/challenges/default.json#L5) I realize that most tasks [seem to be throttled](https://github.com/elastic/rally-tracks/blob/master/geonames/challenges/default.json#L90) by the [`target-throughput`](https://esrally.readthedocs.io/en/stable/track.html#schedule).
I would love to learn about the reasoning behind it. Especially:
1. Why did you limit it? How does it improve the result data?
2. If I would would create a custom track removing those limitations, what would I have to consider when analyzing the results?
It really suprised me, since I am not that knowledgable about benchmarks.
Thank you so much
Lars
**PS:** If it matters, we use pretty big servers for our ES cluster benchmarks (12 core Xeon, 500GB RAM per node)
**Update 2** : Especially since I saw that nyc taxis does both [`default_no_target` and `default`](https://github.com/elastic/rally-tracks/blob/master/nyc_taxis/challenges/default.json#L57) there has to be a reason I dont understand!
---
### Author:  [@Quentin\_Pradet](https://discuss.elastic.co/u/Quentin_Pradet)
#### Post date: [May 12, 2023, 11:04am UTC](https://discuss.elastic.co/t/reasoning-behind-geonames-rally-design/333271/2 "2023-05-12T11:04:28Z")
Hello,
Good question.
So those tracks are designed for our [Elasticsearch benchmarks](https://elasticsearch-benchmarks.elastic.co) page and they are designed to help us find performance regressions in Elasticsearch itself. So we care more about stability than absolute numbers and scalability. That said:
- For indexing, you'll notice that we never throttle and go as fast as possible.
- For querying, we are more interested in latency than throughput and throttling gets use more stable latencies. Regarding `default_no_target` we made some experiments in the NYC track to see the effect of disabling throttling but it was not conclusive and we pause dit.
> Since our HPC environment is batch job dominated, we care more about throughput scalability than the actual latency as it is very unlikely to become a bottleneck in computing-oriented jobs.
Do you care about _queries_ throughput? Or mostly for about indexing throughput like most of our users? If you care more about indexing, then our benchmarks could be good starting point. Otherwise, you may need to tweak them.
And, as always, the best benchmark is always going to be a benchmark based on your data and your latency/throughput requirements. Rally has good docs for [creating your own track](https://esrally.readthedocs.io/en/stable/adding_tracks.html).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [June 9, 2023, 11:04am UTC](https://discuss.elastic.co/t/reasoning-behind-geonames-rally-design/333271/3 "2023-06-09T11:04:38Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.