# Why there isn't an official track to measure the query throughput?

**URL:** https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452
**Category:** Elasticsearch
**Tags:** rally
**Created:** [September 30, 2018, 3:32am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452 "2018-09-30T03:32:25Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Harry\_Lee](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/harry_lee/32/36023_2.png) [@Harry\_Lee](https://discuss.elastic.co/u/Harry_Lee)
#### Post date: [September 30, 2018, 3:32am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452/1 "2018-09-30T03:32:25Z")

</div>

Why there isn't an official track to measure the query throughput?  
Most of the query challenge in the official tracks have a target throughput to 20.  
It seems all the official tracks have a indexing throughput challenge but not query throughput. Why is that?

---

<div class="post-metadata">

### Author: ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [September 30, 2018, 7:15am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452/2 "2018-09-30T07:15:17Z")

</div>

As described in [this blog post](https://www.elastic.co/blog/seven-tips-for-better-elasticsearch-benchmarks) and [this Elastic{ON} talk](https://www.elastic.co/elasticon/conf/2018/sf/the-seven-deadly-sins-of-elasticsearch-benchmarking), throughput and service time affect each other. As you increase throughout and system resources get depleted, service time will inevitably go up. When you benchmark on the maximum throughput a cluster can handle the service time can be quite long.

When you are indexing data, throughput is generally much more important than service time. The time it takes to index a request does often not matter as long as the throughput is good. This is however in my experience rarely the case for queries where there generally always is an SLA around service time that need to be met. When benchmarking queries it is therefore very common to gradually increase the query rate in fixed steps until the SLA is no longer met, which gives the query throughout the cluster can handle.

---

<div class="post-metadata">

### Author: ![Harry\_Lee](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/harry_lee/32/36023_2.png) [@Harry\_Lee](https://discuss.elastic.co/u/Harry_Lee)
#### Post date: [September 30, 2018, 7:24am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452/3 "2018-09-30T07:24:47Z")

</div>

> When benchmarking queries it is therefore very common to gradually increase the query rate in fixed steps until the SLA is no longer met, which gives the query throughout the cluster can handle.

Yes, but it seems I can't find any of the official tracks that gives the query throughout. All the query operations there have a low "target-throughput" limit.

> **[GitHub - elastic/rally-tracks: Track specifications for the Elasticsearch...](https://github.com/elastic/rally-tracks)**
>
> Track specifications for the Elasticsearch benchmarking tool Rally - GitHub - elastic/rally-tracks: Track specifications for the Elasticsearch benchmarking tool Rally

---

<div class="post-metadata">

### Author: ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [September 30, 2018, 7:32am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452/4 "2018-09-30T07:32:15Z")

</div>

As the query latency and throughput will depend a lot on your data and queries, I would recommend you create your own track based on your data and queries. For inspiration you can look at [this challenge from the rally-eventdata-track](https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/combined-indexing-and-querying.json) which shows how you can create a track that gradually increases throughput. In this case it may be the opposite of what you want as I try to find the highest indexing throughput that still gives me acceptable query latencies, but you should be able to use a similar construct for just querying.

---

<div class="post-metadata">

### Author: ![Harry\_Lee](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/harry_lee/32/36023_2.png) [@Harry\_Lee](https://discuss.elastic.co/u/Harry_Lee)
#### Post date: [September 30, 2018, 7:40am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452/5 "2018-09-30T07:40:15Z")

</div>

Okay, I'll check it. Thank you.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [October 28, 2018, 7:45am UTC](https://discuss.elastic.co/t/why-there-isnt-an-official-track-to-measure-the-query-throughput/150452/6 "2018-10-28T07:45:39Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
