Sniffing the type is very fast, there is no way that its taking much
On Friday, May 13, 2011 at 9:32 PM, Paul Loy wrote:
After reprofiling I don't see the script taking up any cpu cycles any more.
I have to verify that it's functionally correct, but looks like a massive
Now the next biggest cpu usage is in deserializing the source into a mapon search results - which is now around 30%.
We use source rather than fields as we've pushed into the index pretty much
everything we need to return to the client app. I think you've said
previously that it's more optimal to use the source rather than fields when
you require a large subset of fields to be returned. We have around 40
---- time passing by ----
We do throw away a percentage of search results based on what a user wants
to ignore so I have now optimized the deserialization process to only
deserialize when I want one (or more) of the fields out of the map. This has
massively reduced the deserialization overhead.
I also just jump straight into a JsonXContent rather than using
XContentFactory.xContent(source).createParser(source). I'm wondering if
InternalSearchHit#sourceAsMap could do the same? Seems we already know it's
going to be Json so why waste cpu cycles sniffing the content?
So, all in all, the native scripts are very highly recommended!
On Fri, May 13, 2011 at 4:00 AM, Shay Banon email@example.com:
Fixed the docs, thanks!. Also, the AbstractFloatSearchScript will be
simpler to use. If you want to share the script you use, then it might be
further optimized (like using ThreadLocalRandom). Hows the perf now?
On Friday, May 13, 2011 at 4:38 AM, Paul Loy wrote:
Looking through the code it's because it should be:
The documentation is slightly wrong (has extraneous 's' chars and says
'type' rather than 'lang').
On Fri, May 13, 2011 at 2:28 AM, Paul Loy firstname.lastname@example.org wrote:
So I put:
into my index settings and that did'nt work. Then I put it into the main
settings and it also didn't work.
I get a stack trace:
search.SearchPhaseExecutionException: Failed to execute phase
[query_fetch], total failure; shardFailures
from,size: Parse Failure [Failed to parse source [
nested: ElasticSearchIllegalArgumentException[Native script [sp_rand] not
On Fri, May 13, 2011 at 1:28 AM, Paul Loy email@example.com wrote:
Ah, I remember seeing that on a changelist / release notes.
On Fri, May 13, 2011 at 12:50 AM, Shay Banon <firstname.lastname@example.org
Which version of elasticsearch are you using? Since 0.16, you can
implement custom Java based scripts that will be faster:
require a sample code integration, I can help.
On Friday, May 13, 2011 at 1:51 AM, Paul Loy wrote:
Profiling our application we see that around 40% of our CPU used is in
executing the script part of our customscorequery.
The only script we have is "random()" in order to get a random list of
results that match our query.
Wondering if there is any way to optimize this?