# Elastic search percolate - Performance
**URL:** https://discuss.elastic.co/t/elastic-search-percolate-performance/106517
**Category:** Elasticsearch
**Created:** [November 6, 2017, 11:51am UTC](https://discuss.elastic.co/t/elastic-search-percolate-performance/106517 "2017-11-06T11:51:24Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@pradeepmurugesan](https://discuss.elastic.co/u/pradeepmurugesan)
#### Post date: [November 6, 2017, 11:51am UTC](https://discuss.elastic.co/t/elastic-search-percolate-performance/106517/1 "2017-11-06T11:51:24Z")
Hello,
we are trying out the elastic search (version 5.5) percolate for our notification feature. But we see the performance is really slow.
```json
{"query": {
"bool": {
"must": [
{
"bool": {
"should": [
{
"term": {
"cType": {
"value": "R",
"boost": 1
}
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"minimum_should_match": "1",
"boost": 1
}
},
{
"terms": {
"oType": [
"O"
],
"boost": 1
}
},
{
"geo_shape": {
"actualLocation": {
"shape": {
"type": "polygon",
"orientation": "right",
"coordinates": [
[
[
[
1.3313,
4.0267
],
[
1.3848,
4.0302
],
[
1.4362,
4.0356
],
[
1.4836,
4.0521
],
[
1.5252,
4.0744
],
[
1.5595,
4.1016
],
[
1.5802,
4.1326
],
[
1.596,
4.1662
],
[
1.6015,
4.201
],
[
1.5964,
4.2362
],
[
1.5809,
4.2699
],
[
1.5556,
4.301
],
[
1.5214,
4.3283
],
[
1.4797,
4.3507
],
[
1.4321,
4.3674
],
[
1.3803,
4.3777
],
[
1.3301,
4.3809
],
[
1.2823,
4.3778
],
[
1.2305,
4.3675
],
[
1.1829,
4.3509
],
[
1.1412,
4.3285
],
[
1.107,
4.3012
],
[
1.0817,
4.2701
],
[
1.0662,
4.2363
],
[
1.061,
4.2013
],
[
1.0666,
4.1662
],
[
1.0824,
4.1326
],
[
1.1031,
4.1016
],
[
1.1374,
4.0744
],
[
1.179,
4.0521
],
[
1.2264,
4.0356
],
[
1.2779,
4.0302
],
[
1.3313,
4.0267
]
]
]
]
},
"relation": "within"
},
"ignore_unmapped": false,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
}
```
We tried to use 50000 such queries and tried to percolate 1 document. All the queries will have a geo-shape as we are dealing with location based documents.
**Questions.**
we have 50000 queries with geo shape in it. In spite of filtering with other criteria, I believe elastic search should at least check the geo-shape for 10000 - 20000 queries.
1. Is the performance expected ?
2. Are you seeing any changes in our query that will increase the performance drastically ?
Kindly help.
Thank you,
Pradeep.
---
### Author:  [@pradeepmurugesan](https://discuss.elastic.co/u/pradeepmurugesan)
#### Post date: [November 6, 2017, 11:52am UTC](https://discuss.elastic.co/t/elastic-search-percolate-performance/106517/2 "2017-11-06T11:52:22Z")
> [@pradeepmurugesan](#):
>
> ied to use 50000 such queries and tried to percolate 1 document. All the queries will have a geo-shape as we are dealing with location based documents.
I already tried the query mentioned [here](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/query-dsl-percolate-query.html#_how_it_works_under_the_hood) and got 0 hits.
I also see an open ticket regarding the performance of the percolation with geo-shape.
>
>
> There are several tasks left around from when the percolator was rewritten in 5.…0 that can be done in order to improve the percolator's performance.
>
> \* \[x\] ~~support for selecting percolator query candidate matches containing wildcard / prefix queries.~~ #25351
> \* \[x\] Document how to deal with wildcard and prefix queries. #27831
> \* \[x\] Add support for selecting percolator query candidate matches containing range queries. #25647
> \* \[\] Add support for selecting percolator query candidate matches containing \`geo\_distance\`, \`geo\_bounding\_box\`, \`geo\_polygon\` and \`geo\_shape\` queries. #26040
> \* \[\] Add support for selecting percolator query candidate matches containing \`geo\_shape\` queries.
> \* \[x\] Today the percolator query's xcontent representation is stored. Alternatively the percolator could also store the percolator query's \`Writable\` representation. This could speed up percolating because parsing the latter format has less overhead. I expect the this improvement to be more noticeable when a percolator query is somewhat more complex (bool query with several clauses) compared to a simple \`term\` query. #25456
> \* \[x\] ~~In case of phrase queries and conjunction queries the percolator only extracts the longest term at index time. The idea here is that only a single term needs to be indexed for the selecting of percolator query candidate matches at search time to work and the longest term is picked because in general that is the rarest term. However that may not always be the case and it would be great if that logic is configurable.~~ #26081 (this change has been superseded by #26307)
> \* \[x\] Change the \`percolate\` query the accept multiple documents (via \`documents\` json object array). This can speed percolation when many documents need to be percolated. The price for parsing and matching percolator queries is only paid once per batch of documents instead of for each document to percolate. #26418
> \* \[x\] Improve extraction of conjunctions in order to have fewer false positives. #26307
The results seemed to be very slow. It took almost 6 seconds. Our actual data set is 250000 queries.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [December 4, 2017, 11:52am UTC](https://discuss.elastic.co/t/elastic-search-percolate-performance/106517/3 "2017-12-04T11:52:28Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.