### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [April 26, 2012, 8:52am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/1 "2012-04-26T08:52:20Z")
Hi Group,
I've read all the info in the net about performance tunning of
elasticsearch, but still not satisfied from the query execution time
of our index.
We have the following:
Hardware:
- 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other 32GB
RAM
- 1GB network hardware, at least 100MB is supported.
Elasticsearch:
- version 19.1
- 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
locked my the elasticsearch. I check this by #cat /proc//status
| grep VmLck - result is: "VmLck: 8864712 kB"
- 2 shards - 1 shard on each server
- no replicas
Documents:
- 10mln documents - average size 2 kb
- each document has 30 string, not\_analyzed, not stored fields.
- average field size - 30 chars
- 5 fields are String arrays - size average 10
- \_all field is disabled
- \_source.compress : true
Query:
- 30 Facets, no facet filters, start:0 size:10
Query Execution time: 5 - 9 sec after the first query.
The only query execution time improvement we achieved was from the
transport.tcp.compress: true option which gave us some 1.5 sec, it was
6.5 - 10 sec before that.
These times are still ok, it is for management reporting, but I really
hope to be able to improve them.
Anybody got better query time performance, and how?
Kind Regards,
Ridvan
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [April 27, 2012, 10:18am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/2 "2012-04-27T10:18:25Z")
Can you share the full search request you execute?
On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan [ridvansg@gmail.com](mailto:ridvansg@gmail.com)wrote:
> Hi Group,
> I've read all the info in the net about performance tunning of
> elasticsearch, but still not satisfied from the query execution time
> of our index.
> We have the following:
> Hardware:
>
> - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other 32GB
> RAM
> - 1GB network hardware, at least 100MB is supported.
>
> Elasticsearch:
>
> - version 19.1
> - 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
> unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
> locked my the elasticsearch. I check this by #cat /proc//status
> | grep VmLck - result is: "VmLck: 8864712 kB"
> - 2 shards - 1 shard on each server
> - no replicas
>
> Documents:
>
> - 10mln documents - average size 2 kb
> - each document has 30 string, not\_analyzed, not stored fields.
> - average field size - 30 chars
> - 5 fields are String arrays - size average 10
> - \_all field is disabled
> - \_source.compress : true
>
> Query:
>
> - 30 Facets, no facet filters, start:0 size:10
> Query Execution time: 5 - 9 sec after the first query.
>
> The only query execution time improvement we achieved was from the
> transport.tcp.compress: true option which gave us some 1.5 sec, it was
> 6.5 - 10 sec before that.
>
> These times are still ok, it is for management reporting, but I really
> hope to be able to improve them.
> Anybody got better query time performance, and how?
>
> Kind Regards,
> Ridvan
---
### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [April 27, 2012, 8:59pm UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/3 "2012-04-27T20:59:34Z")
Hi Shay, here is the full query, some attribute names changed to
f1...fn.
>
I the meantime we noticed that if we remove the term\_stats facet on
the userId field we get some 30% improvement. The userId has 1 mln
different test values, but only one per document.
Kind Regards
On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> Can you share the full search request you execute?
>
> On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com)wrote:
>
> > Hi Group,
> > I've read all the info in the net about performance tunning of
> > elasticsearch, but still not satisfied from the query execution time
> > of our index.
> > We have the following:
> > Hardware:
> >
> > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other 32GB
> > RAM
> > - 1GB network hardware, at least 100MB is supported.
>
> > Elasticsearch:
> >
> > - version 19.1
> > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
> > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
> > locked my the elasticsearch. I check this by #cat /proc//status
> > | grep VmLck - result is: "VmLck: 8864712 kB"
> > - 2 shards - 1 shard on each server
> > - no replicas
>
> > Documents:
> >
> > - 10mln documents - average size 2 kb
> > - each document has 30 string, not\_analyzed, not stored fields.
> > - average field size - 30 chars
> > - 5 fields are String arrays - size average 10
> > - \_all field is disabled
> > - \_source.compress : true
>
> > Query:
> >
> > - 30 Facets, no facet filters, start:0 size:10
> > Query Execution time: 5 - 9 sec after the first query.
>
> > The only query execution time improvement we achieved was from the
> > transport.tcp.compress: true option which gave us some 1.5 sec, it was
> > 6.5 - 10 sec before that.
>
> > These times are still ok, it is for management reporting, but I really
> > hope to be able to improve them.
> > Anybody got better query time performance, and how?
>
> > Kind Regards,
> > Ridvan
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [April 29, 2012, 5:07pm UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/4 "2012-04-29T17:07:51Z")
Those are quite a lot of facets. Is the times you mentioned happen when
data is not being indexed, and if not, can you check (I want to get the
field cache loading out of the picture for a sec)?
Also, one thing that I would do, if you have a dashboard like system, is to
simply use AJAX and multiple search requests, one for each facet, and
display the results for each specific search/facet as them come. Lets see
how this helps things. You can test the same search request with just one
facet and see how long it takes.
Also, I find it strange that you got such a search perf improvement when
compressing the transport, you have a 1gb link. Are the facets big? (you do
get 50 from each one, still strange though...).
On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan [ridvansg@gmail.com](mailto:ridvansg@gmail.com)wrote:
> Hi Shay, here is the full query, some attribute names changed to
> f1...fn.
> [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
>
> I the meantime we noticed that if we remove the term\_stats facet on
> the userId field we get some 30% improvement. The userId has 1 mln
> different test values, but only one per document.
>
> Kind Regards
>
> On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
>
> > Can you share the full search request you execute?
> >
> > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<[ridva...@gmail.com](mailto:ridva...@gmail.com)
> > wrote:
> >
> > > Hi Group,
> > > I've read all the info in the net about performance tunning of
> > > elasticsearch, but still not satisfied from the query execution time
> > > of our index.
> > > We have the following:
> > > Hardware:
> > >
> > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other 32GB
> > > RAM
> > > - 1GB network hardware, at least 100MB is supported.
> >
> > > Elasticsearch:
> > >
> > > - version 19.1
> > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
> > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
> > > locked my the elasticsearch. I check this by #cat /proc//status
> > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > - 2 shards - 1 shard on each server
> > > - no replicas
> >
> > > Documents:
> > >
> > > - 10mln documents - average size 2 kb
> > > - each document has 30 string, not\_analyzed, not stored fields.
> > > - average field size - 30 chars
> > > - 5 fields are String arrays - size average 10
> > > - \_all field is disabled
> > > - \_source.compress : true
> >
> > > Query:
> > >
> > > - 30 Facets, no facet filters, start:0 size:10
> > > Query Execution time: 5 - 9 sec after the first query.
> >
> > > The only query execution time improvement we achieved was from the
> > > transport.tcp.compress: true option which gave us some 1.5 sec, it was
> > > 6.5 - 10 sec before that.
> >
> > > These times are still ok, it is for management reporting, but I really
> > > hope to be able to improve them.
> > > Anybody got better query time performance, and how?
> >
> > > Kind Regards,
> > > Ridvan
---
### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [May 2, 2012, 10:13am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/5 "2012-05-02T10:13:23Z")
Hi Shay,
> Is the times you mentioned happen when
> data is not being indexed, and if not, can you check (I want to get the
> field cache loading out of the picture for a sec)?
> I don't know how to check those, can I check with the spm monitor of
> sematext, or is there other way to do this?
Thanks for the help and Kind Regards,
Ridvan
On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> Those are quite a lot of facets. Is the times you mentioned happen when
> data is not being indexed, and if not, can you check (I want to get the
> field cache loading out of the picture for a sec)?
>
> Also, one thing that I would do, if you have a dashboard like system, is to
> simply use AJAX and multiple search requests, one for each facet, and
> display the results for each specific search/facet as them come. Lets see
> how this helps things. You can test the same search request with just one
> facet and see how long it takes.
>
> Also, I find it strange that you got such a search perf improvement when
> compressing the transport, you have a 1gb link. Are the facets big? (you do
> get 50 from each one, still strange though...).
>
> On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com)wrote:
>
> > Hi Shay, here is the full query, some attribute names changed to
> > f1...fn.
> > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
>
> > I the meantime we noticed that if we remove the term\_stats facet on
> > the userId field we get some 30% improvement. The userId has 1 mln
> > different test values, but only one per document.
>
> > Kind Regards
>
> > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> >
> > > Can you share the full search request you execute?
>
> > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<[ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > wrote:
>
> > > > Hi Group,
> > > > I've read all the info in the net about performance tunning of
> > > > elasticsearch, but still not satisfied from the query execution time
> > > > of our index.
> > > > We have the following:
> > > > Hardware:
> > > >
> > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other 32GB
> > > > RAM
> > > > - 1GB network hardware, at least 100MB is supported.
>
> > > > Elasticsearch:
> > > >
> > > > - version 19.1
> > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
> > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
> > > > locked my the elasticsearch. I check this by #cat /proc//status
> > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > - 2 shards - 1 shard on each server
> > > > - no replicas
>
> > > > Documents:
> > > >
> > > > - 10mln documents - average size 2 kb
> > > > - each document has 30 string, not\_analyzed, not stored fields.
> > > > - average field size - 30 chars
> > > > - 5 fields are String arrays - size average 10
> > > > - \_all field is disabled
> > > > - \_source.compress : true
>
> > > > Query:
> > > >
> > > > - 30 Facets, no facet filters, start:0 size:10
> > > > Query Execution time: 5 - 9 sec after the first query.
>
> > > > The only query execution time improvement we achieved was from the
> > > > transport.tcp.compress: true option which gave us some 1.5 sec, it was
> > > > 6.5 - 10 sec before that.
>
> > > > These times are still ok, it is for management reporting, but I really
> > > > hope to be able to improve them.
> > > > Anybody got better query time performance, and how?
>
> > > > Kind Regards,
> > > > Ridvan
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [May 2, 2012, 4:42pm UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/6 "2012-05-02T16:42:04Z")
On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan [ridvansg@gmail.com](mailto:ridvansg@gmail.com) wrote:
> Hi Shay,
>
> > Is the times you mentioned happen when
> > data is not being indexed, and if not, can you check (I want to get the
> > field cache loading out of the picture for a sec)?
> > I don't know how to check those, can I check with the spm monitor of
> > sematext, or is there other way to do this?
Just execute the query several times, then the facet data will be in
memory. Only once you do that, take measurements.
> Thanks for the help and Kind Regards,
> Ridvan
>
> On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
>
> > Those are quite a lot of facets. Is the times you mentioned happen when
> > data is not being indexed, and if not, can you check (I want to get the
> > field cache loading out of the picture for a sec)?
> >
> > Also, one thing that I would do, if you have a dashboard like system, is
> > to
> > simply use AJAX and multiple search requests, one for each facet, and
> > display the results for each specific search/facet as them come. Lets see
> > how this helps things. You can test the same search request with just one
> > facet and see how long it takes.
> >
> > Also, I find it strange that you got such a search perf improvement when
> > compressing the transport, you have a 1gb link. Are the facets big? (you
> > do
> > get 50 from each one, still strange though...).
> >
> > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<[ridva...@gmail.com](mailto:ridva...@gmail.com)
> > wrote:
> >
> > > Hi Shay, here is the full query, some attribute names changed to
> > > f1...fn.
> > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
> >
> > > I the meantime we noticed that if we remove the term\_stats facet on
> > > the userId field we get some 30% improvement. The userId has 1 mln
> > > different test values, but only one per document.
> >
> > > Kind Regards
> >
> > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > >
> > > > Can you share the full search request you execute?
> >
> > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > wrote:
> >
> > > > > Hi Group,
> > > > > I've read all the info in the net about performance tunning of
> > > > > elasticsearch, but still not satisfied from the query execution
> > > > > time
> > > > > of our index.
> > > > > We have the following:
> > > > > Hardware:
> > > > >
> > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other
> > > > > 32GB
> > > > > RAM
> > > > > - 1GB network hardware, at least 100MB is supported.
> >
> > > > > Elasticsearch:
> > > > >
> > > > > - version 19.1
> > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
> > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
> > > > > locked my the elasticsearch. I check this by #cat
> > > > > /proc//status
> > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > - 2 shards - 1 shard on each server
> > > > > - no replicas
> >
> > > > > Documents:
> > > > >
> > > > > - 10mln documents - average size 2 kb
> > > > > - each document has 30 string, not\_analyzed, not stored fields.
> > > > > - average field size - 30 chars
> > > > > - 5 fields are String arrays - size average 10
> > > > > - \_all field is disabled
> > > > > - \_source.compress : true
> >
> > > > > Query:
> > > > >
> > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > Query Execution time: 5 - 9 sec after the first query.
> >
> > > > > The only query execution time improvement we achieved was from the
> > > > > transport.tcp.compress: true option which gave us some 1.5 sec, it
> > > > > was
> > > > > 6.5 - 10 sec before that.
> >
> > > > > These times are still ok, it is for management reporting, but I
> > > > > really
> > > > > hope to be able to improve them.
> > > > > Anybody got better query time performance, and how?
> >
> > > > > Kind Regards,
> > > > > Ridvan
---
### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [May 2, 2012, 6:27pm UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/7 "2012-05-02T18:27:30Z")
Which API should I use for the measurements of the "field cache
loading"?
๐
On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com) wrote:
>
> > Hi Shay,
> >
> > > Is the times you mentioned happen when
> > > data is not being indexed, and if not, can you check (I want to get the
> > > field cache loading out of the picture for a sec)?
> > > I don't know how to check those, can I check with the spm monitor of
> > > sematext, or is there other way to do this?
>
> Just execute the query several times, then the facet data will be in
> memory. Only once you do that, take measurements.
>
> > Thanks for the help and Kind Regards,
> > Ridvan
>
> > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> >
> > > Those are quite a lot of facets. Is the times you mentioned happen when
> > > data is not being indexed, and if not, can you check (I want to get the
> > > field cache loading out of the picture for a sec)?
>
> > > Also, one thing that I would do, if you have a dashboard like system, is
> > > to
> > > simply use AJAX and multiple search requests, one for each facet, and
> > > display the results for each specific search/facet as them come. Lets see
> > > how this helps things. You can test the same search request with just one
> > > facet and see how long it takes.
>
> > > Also, I find it strange that you got such a search perf improvement when
> > > compressing the transport, you have a 1gb link. Are the facets big? (you
> > > do
> > > get 50 from each one, still strange though...).
>
> > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<[ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > wrote:
>
> > > > Hi Shay, here is the full query, some attribute names changed to
> > > > f1...fn.
> > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
>
> > > > I the meantime we noticed that if we remove the term\_stats facet on
> > > > the userId field we get some 30% improvement. The userId has 1 mln
> > > > different test values, but only one per document.
>
> > > > Kind Regards
>
> > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > >
> > > > > Can you share the full search request you execute?
>
> > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > wrote:
>
> > > > > > Hi Group,
> > > > > > I've read all the info in the net about performance tunning of
> > > > > > elasticsearch, but still not satisfied from the query execution
> > > > > > time
> > > > > > of our index.
> > > > > > We have the following:
> > > > > > Hardware:
> > > > > >
> > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the other
> > > > > > 32GB
> > > > > > RAM
> > > > > > - 1GB network hardware, at least 100MB is supported.
>
> > > > > > Elasticsearch:
> > > > > >
> > > > > > - version 19.1
> > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000 ulimit -l
> > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The memory is
> > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > /proc//status
> > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > - 2 shards - 1 shard on each server
> > > > > > - no replicas
>
> > > > > > Documents:
> > > > > >
> > > > > > - 10mln documents - average size 2 kb
> > > > > > - each document has 30 string, not\_analyzed, not stored fields.
> > > > > > - average field size - 30 chars
> > > > > > - 5 fields are String arrays - size average 10
> > > > > > - \_all field is disabled
> > > > > > - \_source.compress : true
>
> > > > > > Query:
> > > > > >
> > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > Query Execution time: 5 - 9 sec after the first query.
>
> > > > > > The only query execution time improvement we achieved was from the
> > > > > > transport.tcp.compress: true option which gave us some 1.5 sec, it
> > > > > > was
> > > > > > 6.5 - 10 sec before that.
>
> > > > > > These times are still ok, it is for management reporting, but I
> > > > > > really
> > > > > > hope to be able to improve them.
> > > > > > Anybody got better query time performance, and how?
>
> > > > > > Kind Regards,
> > > > > > Ridvan
---
### Author:  [@otisg](https://discuss.elastic.co/u/otisg)
#### Post date: [May 3, 2012, 5:00am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/8 "2012-05-03T05:00:01Z")
Hi Ridvan,
I don't think "field cache loading" (time?) is captured anywhere. If it
is, I'd love to know.
Like Shay said, FC is loaded with field values when you first facet or sort
on a given field. If you facet on field X, when you do it for the first
time, all values from X will be loaded into FC. If you then later facet or
sort on field Y, all values from Y will be loaded into FC when you do that.
## Otis
Performance Monitoring for Solr / Elasticsearch / HBase -
> **[Sematext Monitoring | Infrastructure Monitoring Service](https://sematext.com/spm)**
>
> Bring together your servers, Apps, Metrics, Logs & Events โ Over 40 integrations to easily collect metrics & events across your whole stack โ Start now!
On Wednesday, May 2, 2012 2:27:30 PM UTC-4, Ridvan Gyundogan wrote:
> Which API should I use for the measurements of the "field cache
> loading"?
>
> ๐
>
> On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
>
> > On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > wrote:
> >
> > > Hi Shay,
> > >
> > > > Is the times you mentioned happen when
> > > > data is not being indexed, and if not, can you check (I want to get
> > > > the
> > > > field cache loading out of the picture for a sec)?
> > > > I don't know how to check those, can I check with the spm monitor of
> > > > sematext, or is there other way to do this?
> >
> > Just execute the query several times, then the facet data will be in
> > memory. Only once you do that, take measurements.
> >
> > > Thanks for the help and Kind Regards,
> > > Ridvan
> >
> > > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > >
> > > > Those are quite a lot of facets. Is the times you mentioned happen
> > > > when
> > > > data is not being indexed, and if not, can you check (I want to get
> > > > the
> > > > field cache loading out of the picture for a sec)?
> >
> > > > Also, one thing that I would do, if you have a dashboard like
> > > > system, is
> > > > to
> > > > simply use AJAX and multiple search requests, one for each facet,
> > > > and
> > > > display the results for each specific search/facet as them come.
> > > > Lets see
> > > > how this helps things. You can test the same search request with
> > > > just one
> > > > facet and see how long it takes.
> >
> > > > Also, I find it strange that you got such a search perf improvement
> > > > when
> > > > compressing the transport, you have a 1gb link. Are the facets big?
> > > > (you
> > > > do
> > > > get 50 from each one, still strange though...).
> >
> > > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<
> > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > wrote:
> >
> > > > > Hi Shay, here is the full query, some attribute names changed to
> > > > > f1...fn.
> > > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
> >
> > > > > I the meantime we noticed that if we remove the term\_stats facet
> > > > > on
> > > > > the userId field we get some 30% improvement. The userId has 1 mln
> > > > > different test values, but only one per document.
> >
> > > > > Kind Regards
> >
> > > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > >
> > > > > > Can you share the full search request you execute?
> >
> > > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > wrote:
> >
> > > > > > > Hi Group,
> > > > > > > I've read all the info in the net about performance tunning of
> > > > > > > elasticsearch, but still not satisfied from the query
> > > > > > > execution
> > > > > > > time
> > > > > > > of our index.
> > > > > > > We have the following:
> > > > > > > Hardware:
> > > > > > >
> > > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the
> > > > > > > other
> > > > > > > 32GB
> > > > > > > RAM
> > > > > > > - 1GB network hardware, at least 100MB is supported.
> >
> > > > > > > Elasticsearch:
> > > > > > >
> > > > > > > - version 19.1
> > > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000
> > > > > > > ulimit -l
> > > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The
> > > > > > > memory is
> > > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > > /proc//status
> > > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > > - 2 shards - 1 shard on each server
> > > > > > > - no replicas
> >
> > > > > > > Documents:
> > > > > > >
> > > > > > > - 10mln documents - average size 2 kb
> > > > > > > - each document has 30 string, not\_analyzed, not stored
> > > > > > > fields.
> > > > > > > - average field size - 30 chars
> > > > > > > - 5 fields are String arrays - size average 10
> > > > > > > - \_all field is disabled
> > > > > > > - \_source.compress : true
> >
> > > > > > > Query:
> > > > > > >
> > > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > > Query Execution time: 5 - 9 sec after the first query.
> >
> > > > > > > The only query execution time improvement we achieved was from
> > > > > > > the
> > > > > > > transport.tcp.compress: true option which gave us some 1.5
> > > > > > > sec, it
> > > > > > > was
> > > > > > > 6.5 - 10 sec before that.
> >
> > > > > > > These times are still ok, it is for management reporting, but
> > > > > > > I
> > > > > > > really
> > > > > > > hope to be able to improve them.
> > > > > > > Anybody got better query time performance, and how?
> >
> > > > > > > Kind Regards,
> > > > > > > Ridvan
---
### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [May 3, 2012, 5:55am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/9 "2012-05-03T05:55:58Z")
Hi Otis,
thanks for the hint.
Do you know a API which returns info about the Field Cache status?
I tried things like:
#curl -XGET '[http://localhost:9200/\_status](http://localhost:9200/_status)' \> status.log #grep field
status.log
#curl localhost:9200/\_stats \> stats.log #grep field stats.log
Or if you have other strategies you can improve performance of a query
with 50 term facets using the API or the SPM at sematext?
On May 3, 8:00 am, Otis Gospodnetic [otis.gospodne...@gmail.com](mailto:otis.gospodne...@gmail.com)
wrote:
> Hi Ridvan,
>
> I don't think "field cache loading" (time?) is captured anywhere. If it
> is, I'd love to know.
> Like Shay said, FC is loaded with field values when you first facet or sort
> on a given field. If you facet on field X, when you do it for the first
> time, all values from X will be loaded into FC. If you then later facet or
> sort on field Y, all values from Y will be loaded into FC when you do that.
>
> ## Otis
>
> Performance Monitoring for Solr / Elasticsearch / HBase -[Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm)
>
> On Wednesday, May 2, 2012 2:27:30 PM UTC-4, Ridvan Gyundogan wrote:
>
> > Which API should I use for the measurements of the "field cache
> > loading"?
>
> > ๐
>
> > On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> >
> > > On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > wrote:
> > >
> > > > Hi Shay,
> > > >
> > > > > Is the times you mentioned happen when
> > > > > data is not being indexed, and if not, can you check (I want to get
> > > > > the
> > > > > field cache loading out of the picture for a sec)?
> > > > > I don't know how to check those, can I check with the spm monitor of
> > > > > sematext, or is there other way to do this?
>
> > > Just execute the query several times, then the facet data will be in
> > > memory. Only once you do that, take measurements.
>
> > > > Thanks for the help and Kind Regards,
> > > > Ridvan
>
> > > > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > >
> > > > > Those are quite a lot of facets. Is the times you mentioned happen
> > > > > when
> > > > > data is not being indexed, and if not, can you check (I want to get
> > > > > the
> > > > > field cache loading out of the picture for a sec)?
>
> > > > > Also, one thing that I would do, if you have a dashboard like
> > > > > system, is
> > > > > to
> > > > > simply use AJAX and multiple search requests, one for each facet,
> > > > > and
> > > > > display the results for each specific search/facet as them come.
> > > > > Lets see
> > > > > how this helps things. You can test the same search request with
> > > > > just one
> > > > > facet and see how long it takes.
>
> > > > > Also, I find it strange that you got such a search perf improvement
> > > > > when
> > > > > compressing the transport, you have a 1gb link. Are the facets big?
> > > > > (you
> > > > > do
> > > > > get 50 from each one, still strange though...).
>
> > > > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<
> > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > wrote:
>
> > > > > > Hi Shay, here is the full query, some attribute names changed to
> > > > > > f1...fn.
> > > > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
>
> > > > > > I the meantime we noticed that if we remove the term\_stats facet
> > > > > > on
> > > > > > the userId field we get some 30% improvement. The userId has 1 mln
> > > > > > different test values, but only one per document.
>
> > > > > > Kind Regards
>
> > > > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > >
> > > > > > > Can you share the full search request you execute?
>
> > > > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > wrote:
>
> > > > > > > > Hi Group,
> > > > > > > > I've read all the info in the net about performance tunning of
> > > > > > > > elasticsearch, but still not satisfied from the query
> > > > > > > > execution
> > > > > > > > time
> > > > > > > > of our index.
> > > > > > > > We have the following:
> > > > > > > > Hardware:
> > > > > > > >
> > > > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the
> > > > > > > > other
> > > > > > > > 32GB
> > > > > > > > RAM
> > > > > > > > - 1GB network hardware, at least 100MB is supported.
>
> > > > > > > > Elasticsearch:
> > > > > > > >
> > > > > > > > - version 19.1
> > > > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000
> > > > > > > > ulimit -l
> > > > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The
> > > > > > > > memory is
> > > > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > > > /proc//status
> > > > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > > > - 2 shards - 1 shard on each server
> > > > > > > > - no replicas
>
> > > > > > > > Documents:
> > > > > > > >
> > > > > > > > - 10mln documents - average size 2 kb
> > > > > > > > - each document has 30 string, not\_analyzed, not stored
> > > > > > > > fields.
> > > > > > > > - average field size - 30 chars
> > > > > > > > - 5 fields are String arrays - size average 10
> > > > > > > > - \_all field is disabled
> > > > > > > > - \_source.compress : true
>
> > > > > > > > Query:
> > > > > > > >
> > > > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > > > Query Execution time: 5 - 9 sec after the first query.
>
> > > > > > > > The only query execution time improvement we achieved was from
> > > > > > > > the
> > > > > > > > transport.tcp.compress: true option which gave us some 1.5
> > > > > > > > sec, it
> > > > > > > > was
> > > > > > > > 6.5 - 10 sec before that.
>
> > > > > > > > These times are still ok, it is for management reporting, but
> > > > > > > > I
> > > > > > > > really
> > > > > > > > hope to be able to improve them.
> > > > > > > > Anybody got better query time performance, and how?
>
> > > > > > > > Kind Regards,
> > > > > > > > Ridvan
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [May 4, 2012, 1:14pm UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/10 "2012-05-04T13:14:59Z")
The node stats returns the size of the field cache on each node. What I am
saying is that simply run your searches to warm it and then check perf. In
0.19.4, there will be logs that prints when it gets loaded.
On Thu, May 3, 2012 at 8:55 AM, Ridvan Gyundogan [ridvansg@gmail.com](mailto:ridvansg@gmail.com) wrote:
> Hi Otis,
> thanks for the hint.
> Do you know a API which returns info about the Field Cache status?
>
> I tried things like:
> #curl -XGET '[http://localhost:9200/\_status](http://localhost:9200/_status)' \> status.log #grep field
> status.log
> #curl localhost:9200/\_stats \> stats.log #grep field stats.log
>
> Or if you have other strategies you can improve performance of a query
> with 50 term facets using the API or the SPM at sematext?
>
> On May 3, 8:00 am, Otis Gospodnetic [otis.gospodne...@gmail.com](mailto:otis.gospodne...@gmail.com)
> wrote:
>
> > Hi Ridvan,
> >
> > I don't think "field cache loading" (time?) is captured anywhere. If it
> > is, I'd love to know.
> > Like Shay said, FC is loaded with field values when you first facet or
> > sort
> > on a given field. If you facet on field X, when you do it for the first
> > time, all values from X will be loaded into FC. If you then later facet
> > or
> > sort on field Y, all values from Y will be loaded into FC when you do
> > that.
> >
> > ## Otis
> >
> > Performance Monitoring for Solr / Elasticsearch / HBase -
> > [Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm)
> >
> > On Wednesday, May 2, 2012 2:27:30 PM UTC-4, Ridvan Gyundogan wrote:
> >
> > > Which API should I use for the measurements of the "field cache
> > > loading"?
> >
> > > ๐
> >
> > > On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > >
> > > > On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan \<[ridva...@gmail.com](mailto:ridva...@gmail.com)
> >
> > > wrote:
> > >
> > > > > Hi Shay,
> > > > >
> > > > > > Is the times you mentioned happen when
> > > > > > data is not being indexed, and if not, can you check (I want to
> > > > > > get
> > > > > > the
> > > > > > field cache loading out of the picture for a sec)?
> > > > > > I don't know how to check those, can I check with the spm monitor
> > > > > > of
> > > > > > sematext, or is there other way to do this?
> >
> > > > Just execute the query several times, then the facet data will be in
> > > > memory. Only once you do that, take measurements.
> >
> > > > > Thanks for the help and Kind Regards,
> > > > > Ridvan
> >
> > > > > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > >
> > > > > > Those are quite a lot of facets. Is the times you mentioned
> > > > > > happen
> > > > > > when
> > > > > > data is not being indexed, and if not, can you check (I want to
> > > > > > get
> > > > > > the
> > > > > > field cache loading out of the picture for a sec)?
> >
> > > > > > Also, one thing that I would do, if you have a dashboard like
> > > > > > system, is
> > > > > > to
> > > > > > simply use AJAX and multiple search requests, one for each facet,
> > > > > > and
> > > > > > display the results for each specific search/facet as them come.
> > > > > > Lets see
> > > > > > how this helps things. You can test the same search request with
> > > > > > just one
> > > > > > facet and see how long it takes.
> >
> > > > > > Also, I find it strange that you got such a search perf
> > > > > > improvement
> > > > > > when
> > > > > > compressing the transport, you have a 1gb link. Are the facets
> > > > > > big?
> > > > > > (you
> > > > > > do
> > > > > > get 50 from each one, still strange though...).
> >
> > > > > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<
> > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > wrote:
> >
> > > > > > > Hi Shay, here is the full query, some attribute names changed
> > > > > > > to
> > > > > > > f1...fn.
> > > > > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
> >
> > > > > > > I the meantime we noticed that if we remove the term\_stats
> > > > > > > facet
> > > > > > > on
> > > > > > > the userId field we get some 30% improvement. The userId has 1
> > > > > > > mln
> > > > > > > different test values, but only one per document.
> >
> > > > > > > Kind Regards
> >
> > > > > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > > >
> > > > > > > > Can you share the full search request you execute?
> >
> > > > > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > > wrote:
> >
> > > > > > > > > Hi Group,
> > > > > > > > > I've read all the info in the net about performance
> > > > > > > > > tunning of
> > > > > > > > > elasticsearch, but still not satisfied from the query
> > > > > > > > > execution
> > > > > > > > > time
> > > > > > > > > of our index.
> > > > > > > > > We have the following:
> > > > > > > > > Hardware:
> > > > > > > > >
> > > > > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the
> > > > > > > > > other
> > > > > > > > > 32GB
> > > > > > > > > RAM
> > > > > > > > > - 1GB network hardware, at least 100MB is supported.
> >
> > > > > > > > > Elasticsearch:
> > > > > > > > >
> > > > > > > > > - version 19.1
> > > > > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000
> > > > > > > > > ulimit -l
> > > > > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The
> > > > > > > > > memory is
> > > > > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > > > > /proc//status
> > > > > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > > > > - 2 shards - 1 shard on each server
> > > > > > > > > - no replicas
> >
> > > > > > > > > Documents:
> > > > > > > > >
> > > > > > > > > - 10mln documents - average size 2 kb
> > > > > > > > > - each document has 30 string, not\_analyzed, not stored
> > > > > > > > > fields.
> > > > > > > > > - average field size - 30 chars
> > > > > > > > > - 5 fields are String arrays - size average 10
> > > > > > > > > - \_all field is disabled
> > > > > > > > > - \_source.compress : true
> >
> > > > > > > > > Query:
> > > > > > > > >
> > > > > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > > > > Query Execution time: 5 - 9 sec after the first query.
> >
> > > > > > > > > The only query execution time improvement we achieved was
> > > > > > > > > from
> > > > > > > > > the
> > > > > > > > > transport.tcp.compress: true option which gave us some 1.5
> > > > > > > > > sec, it
> > > > > > > > > was
> > > > > > > > > 6.5 - 10 sec before that.
> >
> > > > > > > > > These times are still ok, it is for management reporting,
> > > > > > > > > but
> > > > > > > > > I
> > > > > > > > > really
> > > > > > > > > hope to be able to improve them.
> > > > > > > > > Anybody got better query time performance, and how?
> >
> > > > > > > > > Kind Regards,
> > > > > > > > > Ridvan
---
### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [May 5, 2012, 4:47am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/11 "2012-05-05T04:47:41Z")
Ah yes, I missed the node stat.
Yes I run the query 3-5 times before the test.
Bellow is the info node stat returns me. I am bit surprised by the
"total\_docs":61mln,"total\_size":"57.5gb". Actually I see only 5 mln
docs in my index?
...
"cache":{"field\_evictions":
0,"field\_size":"4.6gb","field\_size\_in\_bytes":4991690858,"filter\_count":
398,"filter\_evictions":
0,"filter\_size":"227.5mb","filter\_size\_in\_bytes":238637804},"merges":
{"current":0,"current\_docs":
0,"current\_size":"0b","current\_size\_in\_bytes":0,"total":
171024,"total\_time":"2.2h","total\_time\_in\_millis":8259533,"total\_docs":
61440652,"total\_size":"57.5gb","total\_size\_in\_bytes":
61796669360},"refresh":{"total":
1592612,"total\_time":"4.9h","total\_time\_in\_millis":17825972},"flush":
{"total":1511,"total\_time":"1.9h","total\_time\_in\_millis":6935800}}}}}
On May 4, 4:14 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> The node stats returns the size of the field cache on each node. What I am
> saying is that simply run your searches to warm it and then check perf. In
> 0.19.4, there will be logs that prints when it gets loaded.
>
> On Thu, May 3, 2012 at 8:55 AM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com) wrote:
>
> > Hi Otis,
> > thanks for the hint.
> > Do you know a API which returns info about the Field Cache status?
>
> > I tried things like:
> > #curl -XGET '[http://localhost:9200/\_status](http://localhost:9200/_status)'\> status.log #grep field
> > status.log
> > #curl localhost:9200/\_stats \> stats.log #grep field stats.log
>
> > Or if you have other strategies you can improve performance of a query
> > with 50 term facets using the API or the SPM at sematext?
>
> > On May 3, 8:00 am, Otis Gospodnetic [otis.gospodne...@gmail.com](mailto:otis.gospodne...@gmail.com)
> > wrote:
> >
> > > Hi Ridvan,
>
> > > I don't think "field cache loading" (time?) is captured anywhere. If it
> > > is, I'd love to know.
> > > Like Shay said, FC is loaded with field values when you first facet or
> > > sort
> > > on a given field. If you facet on field X, when you do it for the first
> > > time, all values from X will be loaded into FC. If you then later facet
> > > or
> > > sort on field Y, all values from Y will be loaded into FC when you do
> > > that.
>
> > > ## Otis
> > >
> > > Performance Monitoring for Solr / Elasticsearch / HBase -
> > > [Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm)
>
> > > On Wednesday, May 2, 2012 2:27:30 PM UTC-4, Ridvan Gyundogan wrote:
>
> > > > Which API should I use for the measurements of the "field cache
> > > > loading"?
>
> > > > ๐
>
> > > > On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > >
> > > > > On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan \<[ridva...@gmail.com](mailto:ridva...@gmail.com)
>
> > > > wrote:
> > > >
> > > > > > Hi Shay,
> > > > > >
> > > > > > > Is the times you mentioned happen when
> > > > > > > data is not being indexed, and if not, can you check (I want to
> > > > > > > get
> > > > > > > the
> > > > > > > field cache loading out of the picture for a sec)?
> > > > > > > I don't know how to check those, can I check with the spm monitor
> > > > > > > of
> > > > > > > sematext, or is there other way to do this?
>
> > > > > Just execute the query several times, then the facet data will be in
> > > > > memory. Only once you do that, take measurements.
>
> > > > > > Thanks for the help and Kind Regards,
> > > > > > Ridvan
>
> > > > > > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > >
> > > > > > > Those are quite a lot of facets. Is the times you mentioned
> > > > > > > happen
> > > > > > > when
> > > > > > > data is not being indexed, and if not, can you check (I want to
> > > > > > > get
> > > > > > > the
> > > > > > > field cache loading out of the picture for a sec)?
>
> > > > > > > Also, one thing that I would do, if you have a dashboard like
> > > > > > > system, is
> > > > > > > to
> > > > > > > simply use AJAX and multiple search requests, one for each facet,
> > > > > > > and
> > > > > > > display the results for each specific search/facet as them come.
> > > > > > > Lets see
> > > > > > > how this helps things. You can test the same search request with
> > > > > > > just one
> > > > > > > facet and see how long it takes.
>
> > > > > > > Also, I find it strange that you got such a search perf
> > > > > > > improvement
> > > > > > > when
> > > > > > > compressing the transport, you have a 1gb link. Are the facets
> > > > > > > big?
> > > > > > > (you
> > > > > > > do
> > > > > > > get 50 from each one, still strange though...).
>
> > > > > > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<
> > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > wrote:
>
> > > > > > > > Hi Shay, here is the full query, some attribute names changed
> > > > > > > > to
> > > > > > > > f1...fn.
> > > > > > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
>
> > > > > > > > I the meantime we noticed that if we remove the term\_stats
> > > > > > > > facet
> > > > > > > > on
> > > > > > > > the userId field we get some 30% improvement. The userId has 1
> > > > > > > > mln
> > > > > > > > different test values, but only one per document.
>
> > > > > > > > Kind Regards
>
> > > > > > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > > > >
> > > > > > > > > Can you share the full search request you execute?
>
> > > > > > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > > > wrote:
>
> > > > > > > > > > Hi Group,
> > > > > > > > > > I've read all the info in the net about performance
> > > > > > > > > > tunning of
> > > > > > > > > > elasticsearch, but still not satisfied from the query
> > > > > > > > > > execution
> > > > > > > > > > time
> > > > > > > > > > of our index.
> > > > > > > > > > We have the following:
> > > > > > > > > > Hardware:
> > > > > > > > > >
> > > > > > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one 16GB the
> > > > > > > > > > other
> > > > > > > > > > 32GB
> > > > > > > > > > RAM
> > > > > > > > > > - 1GB network hardware, at least 100MB is supported.
>
> > > > > > > > > > Elasticsearch:
> > > > > > > > > >
> > > > > > > > > > - version 19.1
> > > > > > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000
> > > > > > > > > > ulimit -l
> > > > > > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true. The
> > > > > > > > > > memory is
> > > > > > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > > > > > /proc//status
> > > > > > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > > > > > - 2 shards - 1 shard on each server
> > > > > > > > > > - no replicas
>
> > > > > > > > > > Documents:
> > > > > > > > > >
> > > > > > > > > > - 10mln documents - average size 2 kb
> > > > > > > > > > - each document has 30 string, not\_analyzed, not stored
> > > > > > > > > > fields.
> > > > > > > > > > - average field size - 30 chars
> > > > > > > > > > - 5 fields are String arrays - size average 10
> > > > > > > > > > - \_all field is disabled
> > > > > > > > > > - \_source.compress : true
>
> > > > > > > > > > Query:
> > > > > > > > > >
> > > > > > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > > > > > Query Execution time: 5 - 9 sec after the first query.
>
> > > > > > > > > > The only query execution time improvement we achieved was
> > > > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > transport.tcp.compress: true option which gave us some 1.5
> > > > > > > > > > sec, it
> > > > > > > > > > was
> > > > > > > > > > 6.5 - 10 sec before that.
>
> > > > > > > > > > These times are still ok, it is for management reporting,
> > > > > > > > > > but
> > > > > > > > > > I
> > > > > > > > > > really
> > > > > > > > > > hope to be able to improve them.
> > > > > > > > > > Anybody got better query time performance, and how?
>
> > > > > > > > > > Kind Regards,
> > > > > > > > > > Ridvan
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [May 9, 2012, 8:26am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/12 "2012-05-09T08:26:49Z")
Where did you see the docs count? Can you share it as well?
On Sat, May 5, 2012 at 7:47 AM, Ridvan Gyundogan [ridvansg@gmail.com](mailto:ridvansg@gmail.com) wrote:
> Ah yes, I missed the node stat.
> Yes I run the query 3-5 times before the test.
>
> Bellow is the info node stat returns me. I am bit surprised by the
> "total\_docs":61mln,"total\_size":"57.5gb". Actually I see only 5 mln
> docs in my index?
> ...
> "cache":{"field\_evictions":
> 0,"field\_size":"4.6gb","field\_size\_in\_bytes":4991690858,"filter\_count":
> 398,"filter\_evictions":
> 0,"filter\_size":"227.5mb","filter\_size\_in\_bytes":238637804},"merges":
> {"current":0,"current\_docs":
> 0,"current\_size":"0b","current\_size\_in\_bytes":0,"total":
> 171024,"total\_time":"2.2h","total\_time\_in\_millis":8259533,"total\_docs":
> 61440652,"total\_size":"57.5gb","total\_size\_in\_bytes":
> 61796669360},"refresh":{"total":
> 1592612,"total\_time":"4.9h","total\_time\_in\_millis":17825972},"flush":
> {"total":1511,"total\_time":"1.9h","total\_time\_in\_millis":6935800}}}}}
>
> On May 4, 4:14 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
>
> > The node stats returns the size of the field cache on each node. What I
> > am
> > saying is that simply run your searches to warm it and then check perf.
> > In
> > 0.19.4, there will be logs that prints when it gets loaded.
> >
> > On Thu, May 3, 2012 at 8:55 AM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > wrote:
> >
> > > Hi Otis,
> > > thanks for the hint.
> > > Do you know a API which returns info about the Field Cache status?
> >
> > > I tried things like:
> > > #curl -XGET '[http://localhost:9200/\_status](http://localhost:9200/_status)'\> status.log #grep field
> > > status.log
> > > #curl localhost:9200/\_stats \> stats.log #grep field stats.log
> >
> > > Or if you have other strategies you can improve performance of a query
> > > with 50 term facets using the API or the SPM at sematext?
> >
> > > On May 3, 8:00 am, Otis Gospodnetic [otis.gospodne...@gmail.com](mailto:otis.gospodne...@gmail.com)
> > > wrote:
> > >
> > > > Hi Ridvan,
> >
> > > > I don't think "field cache loading" (time?) is captured anywhere.
> > > > If it
> > > > is, I'd love to know.
> > > > Like Shay said, FC is loaded with field values when you first facet
> > > > or
> > > > sort
> > > > on a given field. If you facet on field X, when you do it for the
> > > > first
> > > > time, all values from X will be loaded into FC. If you then later
> > > > facet
> > > > or
> > > > sort on field Y, all values from Y will be loaded into FC when you do
> > > > that.
> >
> > > > ## Otis
> > > >
> > > > Performance Monitoring for Solr / Elasticsearch / HBase -
> > > > [Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm)
> >
> > > > On Wednesday, May 2, 2012 2:27:30 PM UTC-4, Ridvan Gyundogan wrote:
> >
> > > > > Which API should I use for the measurements of the "field cache
> > > > > loading"?
> >
> > > > > ๐
> >
> > > > > On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > >
> > > > > > On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan \<
> > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> >
> > > > > wrote:
> > > > >
> > > > > > > Hi Shay,
> > > > > > >
> > > > > > > > Is the times you mentioned happen when
> > > > > > > > data is not being indexed, and if not, can you check (I want
> > > > > > > > to
> > > > > > > > get
> > > > > > > > the
> > > > > > > > field cache loading out of the picture for a sec)?
> > > > > > > > I don't know how to check those, can I check with the spm
> > > > > > > > monitor
> > > > > > > > of
> > > > > > > > sematext, or is there other way to do this?
> >
> > > > > > Just execute the query several times, then the facet data will
> > > > > > be in
> > > > > > memory. Only once you do that, take measurements.
> >
> > > > > > > Thanks for the help and Kind Regards,
> > > > > > > Ridvan
> >
> > > > > > > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > > >
> > > > > > > > Those are quite a lot of facets. Is the times you mentioned
> > > > > > > > happen
> > > > > > > > when
> > > > > > > > data is not being indexed, and if not, can you check (I want
> > > > > > > > to
> > > > > > > > get
> > > > > > > > the
> > > > > > > > field cache loading out of the picture for a sec)?
> >
> > > > > > > > Also, one thing that I would do, if you have a dashboard like
> > > > > > > > system, is
> > > > > > > > to
> > > > > > > > simply use AJAX and multiple search requests, one for each
> > > > > > > > facet,
> > > > > > > > and
> > > > > > > > display the results for each specific search/facet as them
> > > > > > > > come.
> > > > > > > > Lets see
> > > > > > > > how this helps things. You can test the same search request
> > > > > > > > with
> > > > > > > > just one
> > > > > > > > facet and see how long it takes.
> >
> > > > > > > > Also, I find it strange that you got such a search perf
> > > > > > > > improvement
> > > > > > > > when
> > > > > > > > compressing the transport, you have a 1gb link. Are the
> > > > > > > > facets
> > > > > > > > big?
> > > > > > > > (you
> > > > > > > > do
> > > > > > > > get 50 from each one, still strange though...).
> >
> > > > > > > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<
> > > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > > wrote:
> >
> > > > > > > > > Hi Shay, here is the full query, some attribute names
> > > > > > > > > changed
> > > > > > > > > to
> > > > > > > > > f1...fn.
> > > > > > > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
> >
> > > > > > > > > I the meantime we noticed that if we remove the term\_stats
> > > > > > > > > facet
> > > > > > > > > on
> > > > > > > > > the userId field we get some 30% improvement. The userId
> > > > > > > > > has 1
> > > > > > > > > mln
> > > > > > > > > different test values, but only one per document.
> >
> > > > > > > > > Kind Regards
> >
> > > > > > > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > > > > >
> > > > > > > > > > Can you share the full search request you execute?
> >
> > > > > > > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > > > > wrote:
> >
> > > > > > > > > > > Hi Group,
> > > > > > > > > > > I've read all the info in the net about performance
> > > > > > > > > > > tunning of
> > > > > > > > > > > elasticsearch, but still not satisfied from the query
> > > > > > > > > > > execution
> > > > > > > > > > > time
> > > > > > > > > > > of our index.
> > > > > > > > > > > We have the following:
> > > > > > > > > > > Hardware:
> > > > > > > > > > >
> > > > > > > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one
> > > > > > > > > > > 16GB the
> > > > > > > > > > > other
> > > > > > > > > > > 32GB
> > > > > > > > > > > RAM
> > > > > > > > > > > - 1GB network hardware, at least 100MB is supported.
> >
> > > > > > > > > > > Elasticsearch:
> > > > > > > > > > >
> > > > > > > > > > > - version 19.1
> > > > > > > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000
> > > > > > > > > > > ulimit -l
> > > > > > > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true.
> > > > > > > > > > > The
> > > > > > > > > > > memory is
> > > > > > > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > > > > > > /proc//status
> > > > > > > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > > > > > > - 2 shards - 1 shard on each server
> > > > > > > > > > > - no replicas
> >
> > > > > > > > > > > Documents:
> > > > > > > > > > >
> > > > > > > > > > > - 10mln documents - average size 2 kb
> > > > > > > > > > > - each document has 30 string, not\_analyzed, not stored
> > > > > > > > > > > fields.
> > > > > > > > > > > - average field size - 30 chars
> > > > > > > > > > > - 5 fields are String arrays - size average 10
> > > > > > > > > > > - \_all field is disabled
> > > > > > > > > > > - \_source.compress : true
> >
> > > > > > > > > > > Query:
> > > > > > > > > > >
> > > > > > > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > > > > > > Query Execution time: 5 - 9 sec after the first query.
> >
> > > > > > > > > > > The only query execution time improvement we achieved
> > > > > > > > > > > was
> > > > > > > > > > > from
> > > > > > > > > > > the
> > > > > > > > > > > transport.tcp.compress: true option which gave us some
> > > > > > > > > > > 1.5
> > > > > > > > > > > sec, it
> > > > > > > > > > > was
> > > > > > > > > > > 6.5 - 10 sec before that.
> >
> > > > > > > > > > > These times are still ok, it is for management
> > > > > > > > > > > reporting,
> > > > > > > > > > > but
> > > > > > > > > > > I
> > > > > > > > > > > really
> > > > > > > > > > > hope to be able to improve them.
> > > > > > > > > > > Anybody got better query time performance, and how?
> >
> > > > > > > > > > > Kind Regards,
> > > > > > > > > > > Ridvan
---
### Author:  [@Ridvan\_Gyundogan](https://discuss.elastic.co/u/Ridvan_Gyundogan)
#### Post date: [May 10, 2012, 5:39pm UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/13 "2012-05-10T17:39:33Z")
Hi Shay,
It is on the pasted json response from the node stats message above.
Or:
#curl -XGET '[http://localhost:9200/\_nodes/stats](http://localhost:9200/_nodes/stats)' | tr "," "\n" | grep
total\_docs
"total\_docs":61440652 (61mln)
After restarting the server, this same curl call is now giving me
result which makes sense:
"total\_docs":8652280(8mln)
I have somethilg like 4 mln docs which I check from the Indeces stats:
#curl localhost:9200/\_stats |tr "{" "-" | tr "}" "\n" | grep total |
grep docs
,"total":-"docs":-"count":4265820,"deleted":1281712
I index something like 50 docs per second with TTL 1 day.
Kind Regards
On May 9, 11:26 am, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> Where did you see the docs count? Can you share it as well?
>
> On Sat, May 5, 2012 at 7:47 AM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com) wrote:
>
> > Ah yes, I missed the node stat.
> > Yes I run the query 3-5 times before the test.
>
> > Bellow is the info node stat returns me. I am bit surprised by the
> > "total\_docs":61mln,"total\_size":"57.5gb". Actually I see only 5 mln
> > docs in my index?
> > ...
> > "cache":{"field\_evictions":
> > 0,"field\_size":"4.6gb","field\_size\_in\_bytes":4991690858,"filter\_count":
> > 398,"filter\_evictions":
> > 0,"filter\_size":"227.5mb","filter\_size\_in\_bytes":238637804},"merges":
> > {"current":0,"current\_docs":
> > 0,"current\_size":"0b","current\_size\_in\_bytes":0,"total":
> > 171024,"total\_time":"2.2h","total\_time\_in\_millis":8259533,"total\_docs":
> > 61440652,"total\_size":"57.5gb","total\_size\_in\_bytes":
> > 61796669360},"refresh":{"total":
> > 1592612,"total\_time":"4.9h","total\_time\_in\_millis":17825972},"flush":
> > {"total":1511,"total\_time":"1.9h","total\_time\_in\_millis":6935800}}}}}
>
> > On May 4, 4:14 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> >
> > > The node stats returns the size of the field cache on each node. What I
> > > am
> > > saying is that simply run your searches to warm it and then check perf.
> > > In
> > > 0.19.4, there will be logs that prints when it gets loaded.
>
> > > On Thu, May 3, 2012 at 8:55 AM, Ridvan Gyundogan [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > wrote:
> > >
> > > > Hi Otis,
> > > > thanks for the hint.
> > > > Do you know a API which returns info about the Field Cache status?
>
> > > > I tried things like:
> > > > #curl -XGET '[http://localhost:9200/\_status](http://localhost:9200/_status)'\> status.log #grep field
> > > > status.log
> > > > #curl localhost:9200/\_stats \> stats.log #grep field stats.log
>
> > > > Or if you have other strategies you can improve performance of a query
> > > > with 50 term facets using the API or the SPM at sematext?
>
> > > > On May 3, 8:00 am, Otis Gospodnetic [otis.gospodne...@gmail.com](mailto:otis.gospodne...@gmail.com)
> > > > wrote:
> > > >
> > > > > Hi Ridvan,
>
> > > > > I don't think "field cache loading" (time?) is captured anywhere.
> > > > > If it
> > > > > is, I'd love to know.
> > > > > Like Shay said, FC is loaded with field values when you first facet
> > > > > or
> > > > > sort
> > > > > on a given field. If you facet on field X, when you do it for the
> > > > > first
> > > > > time, all values from X will be loaded into FC. If you then later
> > > > > facet
> > > > > or
> > > > > sort on field Y, all values from Y will be loaded into FC when you do
> > > > > that.
>
> > > > > ## Otis
> > > > >
> > > > > Performance Monitoring for Solr / Elasticsearch / HBase -
> > > > > [Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm)
>
> > > > > On Wednesday, May 2, 2012 2:27:30 PM UTC-4, Ridvan Gyundogan wrote:
>
> > > > > > Which API should I use for the measurements of the "field cache
> > > > > > loading"?
>
> > > > > > ๐
>
> > > > > > On May 2, 7:42 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > >
> > > > > > > On Wed, May 2, 2012 at 1:13 PM, Ridvan Gyundogan \<
> > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
>
> > > > > > wrote:
> > > > > >
> > > > > > > > Hi Shay,
> > > > > > > >
> > > > > > > > > Is the times you mentioned happen when
> > > > > > > > > data is not being indexed, and if not, can you check (I want
> > > > > > > > > to
> > > > > > > > > get
> > > > > > > > > the
> > > > > > > > > field cache loading out of the picture for a sec)?
> > > > > > > > > I don't know how to check those, can I check with the spm
> > > > > > > > > monitor
> > > > > > > > > of
> > > > > > > > > sematext, or is there other way to do this?
>
> > > > > > > Just execute the query several times, then the facet data will
> > > > > > > be in
> > > > > > > memory. Only once you do that, take measurements.
>
> > > > > > > > Thanks for the help and Kind Regards,
> > > > > > > > Ridvan
>
> > > > > > > > On Apr 29, 8:07 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > > > >
> > > > > > > > > Those are quite a lot of facets. Is the times you mentioned
> > > > > > > > > happen
> > > > > > > > > when
> > > > > > > > > data is not being indexed, and if not, can you check (I want
> > > > > > > > > to
> > > > > > > > > get
> > > > > > > > > the
> > > > > > > > > field cache loading out of the picture for a sec)?
>
> > > > > > > > > Also, one thing that I would do, if you have a dashboard like
> > > > > > > > > system, is
> > > > > > > > > to
> > > > > > > > > simply use AJAX and multiple search requests, one for each
> > > > > > > > > facet,
> > > > > > > > > and
> > > > > > > > > display the results for each specific search/facet as them
> > > > > > > > > come.
> > > > > > > > > Lets see
> > > > > > > > > how this helps things. You can test the same search request
> > > > > > > > > with
> > > > > > > > > just one
> > > > > > > > > facet and see how long it takes.
>
> > > > > > > > > Also, I find it strange that you got such a search perf
> > > > > > > > > improvement
> > > > > > > > > when
> > > > > > > > > compressing the transport, you have a 1gb link. Are the
> > > > > > > > > facets
> > > > > > > > > big?
> > > > > > > > > (you
> > > > > > > > > do
> > > > > > > > > get 50 from each one, still strange though...).
>
> > > > > > > > > On Fri, Apr 27, 2012 at 11:59 PM, Ridvan Gyundogan \<
> > > > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > > > wrote:
>
> > > > > > > > > > Hi Shay, here is the full query, some attribute names
> > > > > > > > > > changed
> > > > > > > > > > to
> > > > > > > > > > f1...fn.
> > > > > > > > > > [Query on the whole index ยท GitHub](https://gist.github.com/2513068)
>
> > > > > > > > > > I the meantime we noticed that if we remove the term\_stats
> > > > > > > > > > facet
> > > > > > > > > > on
> > > > > > > > > > the userId field we get some 30% improvement. The userId
> > > > > > > > > > has 1
> > > > > > > > > > mln
> > > > > > > > > > different test values, but only one per document.
>
> > > > > > > > > > Kind Regards
>
> > > > > > > > > > On Apr 27, 1:18 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> > > > > > > > > >
> > > > > > > > > > > Can you share the full search request you execute?
>
> > > > > > > > > > > On Thu, Apr 26, 2012 at 11:52 AM, Ridvan Gyundogan \<
> > > > > > > > > > > [ridva...@gmail.com](mailto:ridva...@gmail.com)
> > > > > > > > > > > wrote:
>
> > > > > > > > > > > > Hi Group,
> > > > > > > > > > > > I've read all the info in the net about performance
> > > > > > > > > > > > tunning of
> > > > > > > > > > > > elasticsearch, but still not satisfied from the query
> > > > > > > > > > > > execution
> > > > > > > > > > > > time
> > > > > > > > > > > > of our index.
> > > > > > > > > > > > We have the following:
> > > > > > > > > > > > Hardware:
> > > > > > > > > > > >
> > > > > > > > > > > > - 2 bare metal AMD machines, each 6 core 3Ghz, one
> > > > > > > > > > > > 16GB the
> > > > > > > > > > > > other
> > > > > > > > > > > > 32GB
> > > > > > > > > > > > RAM
> > > > > > > > > > > > - 1GB network hardware, at least 100MB is supported.
>
> > > > > > > > > > > > Elasticsearch:
> > > > > > > > > > > >
> > > > > > > > > > > > - version 19.1
> > > > > > > > > > > > - 8GB RAM dedicated to elasticsearch. ulimit -n 100000
> > > > > > > > > > > > ulimit -l
> > > > > > > > > > > > unlimited ES\_HEAP\_SIZE=8g, bootstrap.mlockall: true.
> > > > > > > > > > > > The
> > > > > > > > > > > > memory is
> > > > > > > > > > > > locked my the elasticsearch. I check this by #cat
> > > > > > > > > > > > /proc//status
> > > > > > > > > > > > | grep VmLck - result is: "VmLck: 8864712 kB"
> > > > > > > > > > > > - 2 shards - 1 shard on each server
> > > > > > > > > > > > - no replicas
>
> > > > > > > > > > > > Documents:
> > > > > > > > > > > >
> > > > > > > > > > > > - 10mln documents - average size 2 kb
> > > > > > > > > > > > - each document has 30 string, not\_analyzed, not stored
> > > > > > > > > > > > fields.
> > > > > > > > > > > > - average field size - 30 chars
> > > > > > > > > > > > - 5 fields are String arrays - size average 10
> > > > > > > > > > > > - \_all field is disabled
> > > > > > > > > > > > - \_source.compress : true
>
> > > > > > > > > > > > Query:
> > > > > > > > > > > >
> > > > > > > > > > > > - 30 Facets, no facet filters, start:0 size:10
> > > > > > > > > > > > Query Execution time: 5 - 9 sec after the first query.
>
> > > > > > > > > > > > The only query execution time improvement we achieved
> > > > > > > > > > > > was
> > > > > > > > > > > > from
> > > > > > > > > > > > the
> > > > > > > > > > > > transport.tcp.compress: true option which gave us some
> > > > > > > > > > > > 1.5
> > > > > > > > > > > > sec, it
> > > > > > > > > > > > was
> > > > > > > > > > > > 6.5 - 10 sec before that.
>
> > > > > > > > > > > > These times are still ok, it is for management
> > > > > > > > > > > > reporting,
> > > > > > > > > > > > but
> > > > > > > > > > > > I
> > > > > > > > > > > > really
> > > > > > > > > > > > hope to be able to improve them.
> > > > > > > > > > > > Anybody got better query time performance, and how?
>
> > > > > > > > > > > > Kind Regards,
> > > > > > > > > > > > Ridvan
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 3:29am UTC](https://discuss.elastic.co/t/query-execution-time-performance/7472/14 "2017-07-06T03:29:24Z")