# Custom\_score query performance hit

**URL:** <https://discuss.elastic.co/t/custom-score-query-performance-hit/13018>\
**Category:** Elasticsearch\
**Created:** [July 31, 2013, 3:56pm UTC](https://discuss.elastic.co/t/custom-score-query-performance-hit/13018 "2013-07-31T15:56:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Justin\_Treher](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/justin_treher/32/45243_2.png) [@Justin\_Treher](https://discuss.elastic.co/u/Justin_Treher)\
**Post date:** [July 31, 2013, 3:56pm UTC](https://discuss.elastic.co/t/custom-score-query-performance-hit/13018/1 "2013-07-31T15:56:08Z")

</div>

I a bit curious about the effect of custom\_score on performance and what I  
might do to help the situation. I present three different and very simple  
cases.

1. A basic match\_all with a custom\_score wrapper with no additional  
scripting functions. This returns in 20ms. Not so bad.

{  
"query": {  
"custom\_score": {  
"query": {  
"match\_all": {}  
},  
"script": "\_score"  
}  
}  
}

1. Same thing without the custom\_score is considerably faster. Makes the  
20ms above seem horrible.  
{  
"query": {  
"match\_all": {}  
}  
}

2. Finally, when I add a size and, much worse, a fields restriction, the  
time jumps to 70ms. Without the custom score, the queries are consistently  
around 2ms, regardless of size or fields.

{  
"query": {  
"custom\_score": {  
"query": {  
"match\_all": {}  
},  
"script": "\_score"  
}  
},  
"size": 500,  
"fields": [  
"id"  
]  
}

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\
**Post date:** [August 5, 2013, 1:10pm UTC](https://discuss.elastic.co/t/custom-score-query-performance-hit/13018/2 "2013-08-05T13:10:23Z")

</div>

Hi Justin,  
the script gets executed for each document, thus the more documents you get  
back, the more time will be spent there.

The fields directive could cause worse performance too if the id field is  
not stored, since the \_source would get parsed and only the id field would  
get returned out of it, while by default the whole \_source would be  
returned, that's it.

Have you tried making those changes separately? Only increase the size and  
measure the time, and only add the fields directive and measure the time?

Also, that kind of test would make more sense with a real script and your  
real usage of elasticsearch. Are you planning to only retrieve the id field  
back from elasticsearch?

On Wednesday, July 31, 2013 5:56:08 PM UTC+2, Justin Treher wrote:

> I a bit curious about the effect of custom\_score on performance and what I  
> might do to help the situation. I present three different and very simple  
> cases.
> 
> 1. A basic match\_all with a custom\_score wrapper with no additional  
> scripting functions. This returns in 20ms. Not so bad.
> 
> {  
> "query": {  
> "custom\_score": {  
> "query": {  
> "match\_all": {}  
> },  
> "script": "\_score"  
> }  
> }  
> }
> 
> 1. Same thing without the custom\_score is considerably faster. Makes the  
> 20ms above seem horrible.  
> {  
> "query": {  
> "match\_all": {}  
> }  
> }
> 
> 2. Finally, when I add a size and, much worse, a fields restriction, the  
> time jumps to 70ms. Without the custom score, the queries are consistently  
> around 2ms, regardless of size or fields.
> 
> {  
> "query": {  
> "custom\_score": {  
> "query": {  
> "match\_all": {}  
> },  
> "script": "\_score"  
> }  
> },  
> "size": 500,  
> "fields": [  
> "id"  
> ]  
> }

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\
**Post date:** [August 5, 2013, 1:23pm UTC](https://discuss.elastic.co/t/custom-score-query-performance-hit/13018/3 "2013-08-05T13:23:15Z")

</div>

Hi Justin,  
part of my reply was incorrect, sorry about that 🙂 Thinking more about it,  
it's not true that the size influences the time spent on executing the  
script. In a custom score query the script is executed to compute the score  
of all documents, not only the ones that get returned (which you can  
control through the size parameter. Thus if the number of documents that  
match the query is the same, the total time spent on running the script  
should be pretty much the same, since it's run on the same number of  
documents.

I'd also add that it is pretty normal that a match\_all query is fast. I  
would run tests with real queries that you are going to use.

On Monday, August 5, 2013 3:10:23 PM UTC+2, Luca Cavanna wrote:

> Hi Justin,  
> the script gets executed for each document, thus the more documents you  
> get back, the more time will be spent there.
> 
> The fields directive could cause worse performance too if the id field is  
> not stored, since the \_source would get parsed and only the id field would  
> get returned out of it, while by default the whole \_source would be  
> returned, that's it.
> 
> Have you tried making those changes separately? Only increase the size and  
> measure the time, and only add the fields directive and measure the time?
> 
> Also, that kind of test would make more sense with a real script and your  
> real usage of elasticsearch. Are you planning to only retrieve the id field  
> back from elasticsearch?
> 
> On Wednesday, July 31, 2013 5:56:08 PM UTC+2, Justin Treher wrote:
> 
> > I a bit curious about the effect of custom\_score on performance and what  
> > I might do to help the situation. I present three different and very simple  
> > cases.
> > 
> > 1. A basic match\_all with a custom\_score wrapper with no additional  
> > scripting functions. This returns in 20ms. Not so bad.
> > 
> > {  
> > "query": {  
> > "custom\_score": {  
> > "query": {  
> > "match\_all": {}  
> > },  
> > "script": "\_score"  
> > }  
> > }  
> > }
> > 
> > 1. Same thing without the custom\_score is considerably faster. Makes the  
> > 20ms above seem horrible.  
> > {  
> > "query": {  
> > "match\_all": {}  
> > }  
> > }
> > 
> > 2. Finally, when I add a size and, much worse, a fields restriction, the  
> > time jumps to 70ms. Without the custom score, the queries are consistently  
> > around 2ms, regardless of size or fields.
> > 
> > {  
> > "query": {  
> > "custom\_score": {  
> > "query": {  
> > "match\_all": {}  
> > },  
> > "script": "\_score"  
> > }  
> > },  
> > "size": 500,  
> > "fields": [  
> > "id"  
> > ]  
> > }

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Justin\_Treher](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/justin_treher/32/45243_2.png) [@Justin\_Treher](https://discuss.elastic.co/u/Justin_Treher)\
**Post date:** [August 5, 2013, 2:46pm UTC](https://discuss.elastic.co/t/custom-score-query-performance-hit/13018/4 "2013-08-05T14:46:34Z")

</div>

Hi Luca,

Thank you for the feedback on how custom\_score works relative to doc size.

In all my testing, the custom\_score is adding substantial time whether it  
be a match\_all() or the full blown complex query I send through. It's  
completely relative. Again, I'm not even adding anything to the custom  
score except for the base \_score parameter. I just don't understand the  
magnitude of time that custom score is adding (50ms+/-).

The fields param doesn't seem to be impacting performance at all.

JT

On Monday, August 5, 2013 9:23:15 AM UTC-4, Luca Cavanna wrote:

> Hi Justin,  
> part of my reply was incorrect, sorry about that 🙂 Thinking more about  
> it, it's not true that the size influences the time spent on executing the  
> script. In a custom score query the script is executed to compute the score  
> of all documents, not only the ones that get returned (which you can  
> control through the size parameter. Thus if the number of documents that  
> match the query is the same, the total time spent on running the script  
> should be pretty much the same, since it's run on the same number of  
> documents.
> 
> I'd also add that it is pretty normal that a match\_all query is fast. I  
> would run tests with real queries that you are going to use.
> 
> On Monday, August 5, 2013 3:10:23 PM UTC+2, Luca Cavanna wrote:
> 
> > Hi Justin,  
> > the script gets executed for each document, thus the more documents you  
> > get back, the more time will be spent there.
> > 
> > The fields directive could cause worse performance too if the id field is  
> > not stored, since the \_source would get parsed and only the id field would  
> > get returned out of it, while by default the whole \_source would be  
> > returned, that's it.
> > 
> > Have you tried making those changes separately? Only increase the size  
> > and measure the time, and only add the fields directive and measure the  
> > time?
> > 
> > Also, that kind of test would make more sense with a real script and your  
> > real usage of elasticsearch. Are you planning to only retrieve the id field  
> > back from elasticsearch?
> > 
> > On Wednesday, July 31, 2013 5:56:08 PM UTC+2, Justin Treher wrote:
> > 
> > > I a bit curious about the effect of custom\_score on performance and what  
> > > I might do to help the situation. I present three different and very simple  
> > > cases.
> > > 
> > > 1. A basic match\_all with a custom\_score wrapper with no additional  
> > > scripting functions. This returns in 20ms. Not so bad.
> > > 
> > > {  
> > > "query": {  
> > > "custom\_score": {  
> > > "query": {  
> > > "match\_all": {}  
> > > },  
> > > "script": "\_score"  
> > > }  
> > > }  
> > > }
> > > 
> > > 1. Same thing without the custom\_score is considerably faster. Makes the  
> > > 20ms above seem horrible.  
> > > {  
> > > "query": {  
> > > "match\_all": {}  
> > > }  
> > > }
> > > 
> > > 2. Finally, when I add a size and, much worse, a fields restriction, the  
> > > time jumps to 70ms. Without the custom score, the queries are consistently  
> > > around 2ms, regardless of size or fields.
> > > 
> > > {  
> > > "query": {  
> > > "custom\_score": {  
> > > "query": {  
> > > "match\_all": {}  
> > > },  
> > > "script": "\_score"  
> > > }  
> > > },  
> > > "size": 500,  
> > > "fields": [  
> > > "id"  
> > > ]  
> > > }

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<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:** [July 6, 2017, 2:22am UTC](https://discuss.elastic.co/t/custom-score-query-performance-hit/13018/5 "2017-07-06T02:22:53Z")

</div>