# Rally Benchmark - Which race/benchmark to use for performance testing **URL:** \ **Category:** Elasticsearch\ **Tags:** rally\ **Created:** [November 23, 2021, 11:04pm UTC](https://discuss.elastic.co/t/rally-benchmark-which-race-benchmark-to-use-for-performance-testing/289994 "2021-11-23T23:04:09Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![mmadhana](https://avatars.discourse-cdn.com/v4/letter/m/d2c977/32.png) [@mmadhana](https://discuss.elastic.co/u/mmadhana)\ **Post date:** [November 23, 2021, 11:04pm UTC](https://discuss.elastic.co/t/rally-benchmark-which-race-benchmark-to-use-for-performance-testing/289994/1 "2021-11-23T23:04:09Z")
Hi, I am using Rally on ECK to test the performance of my hardware - CPU cores/memory, storage, and network usage. Which benchmark/race is compute-intensive and has a mix of indexing and concurrent search workload? I used NYC Taxis, not sure if it is the right test. Could you please help? ---
**Author:** ![Bradley\_Deam](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bradley_deam/32/52991_2.png) [@Bradley\_Deam](https://discuss.elastic.co/u/Bradley_Deam)\ **Post date:** [November 29, 2021, 4:55am UTC](https://discuss.elastic.co/t/rally-benchmark-which-race-benchmark-to-use-for-performance-testing/289994/2 "2021-11-29T04:55:57Z")
Hi @mmadhana - apologies for the delayed response here! > Which benchmark/race is compute-intensive and has a mix of indexing and concurrent search workload? I used NYC Taxis, not sure if it is the right test. Could you please help? We actually recently [added concurrent indexing & querying to both the NYC Taxis and PMC tracks](https://github.com/elastic/rally-tracks/pull/196), so you can use either of these, however with benchmarking it's usually preferred to identify a track that represents your intended production workload as closely as possible, or create your own custom track if there's nothing already available. If you have workloads that use document models/sizes and queries that are similar to that of the NYC Taxis track, then that's great! If not, then my suggestion would be to create a [custom track](https://esrally.readthedocs.io/en/stable/adding_tracks.html#define-custom-workloads-tracks) using data that is as close to your workload as possible (note you can [create a track from data in an existing cluster using Rally](https://esrally.readthedocs.io/en/stable/adding_tracks.html#creating-a-track-from-data-in-an-existing-cluster)), that way you can get a more accurate idea of system resource utilisation with data that is close to what will be seen in a production environment, rather than running an arbitrary benchmarking experiment that is not likely to give you accurate ideas of projected throughput and latencies. I'd also like to add that if you do want to try out the NYC Taxis track (or any other, for that matter) and find that your hardware isn't being fully utilised, [you should look at adjusting](https://github.com/elastic/rally-tracks/tree/master/nyc_taxis#parameters) the `bulk_size`, `bulk_indexing_clients`, and/or the `number_of_shards` under `index_settings` to something that makes sense for your cluster - e.g. you may want to set `number_of_shards` equal to the number of nodes in the benchmark target cluster. Lastly, I'd strongly recommend taking a look at this ElasticON presentation on benchmarking Elasticsearch: "[The Seven Deadly Sins of Elasticsearch Benchmarking](https://www.elastic.co/elasticon/conf/2018/sf/the-seven-deadly-sins-of-elasticsearch-benchmarking)" - that'll make sure you don't run into any of the common pitfalls made when attempting to run benchmarks. I hope this helps! ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 27, 2021, 4:56am UTC](https://discuss.elastic.co/t/rally-benchmark-which-race-benchmark-to-use-for-performance-testing/289994/3 "2021-12-27T04:56:47Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.