On another note, since response time is in question, I have been using a
customhighlighter to just override the method encodeSnippets() in the
UnifiedSolrHighlighter class since solr 6 since Solr sends back blank array
(ZERO_LEN_STR_ARRAY) in the response payload for fields that do not match.
Here is the code before:
if (snippet == null) {
//TODO reuse logic of DefaultSolrHighlighter.alternateField
summary.add(field, ZERO_LEN_STR_ARRAY);
} ....
So I had removed this clause and made the following change:
if (snippet != null) {
// we used a special snippet separator char and we can now split on
it.
summary.add(field, snippet.split(SNIPPET_SEPARATOR));
}
This has not changed in Solr 8 too, which for 76 fields gives a very large
payload. So I will keep this custom code for now.
On Fri, Jan 29, 2021 at 12:28 PM Kerwin <[email protected]> wrote:
> Hi David,
>
> Thanks so much for your reply.
> hl.weightMatches was indeed the culprit. After setting it to false, I am
> now getting the same sub-second response as Solr 6. I am using Solr 8.6.1
> (<luceneMatchVersion>8.6.1</luceneMatchVersion>)
>
> Here are the tests I carried out:
> hl.requireFieldMatch=true&hl.weightMatches=true (2458 ms)
> hl.requireFieldMatch=false&hl.weightMatches=true (3964 ms)
> hl.requireFieldMatch=true&hl.weightMatches=false (158 ms)
> hl.requireFieldMatch=false&hl.weightMatches=false (169 ms) (CHOSEN since
> this is consistent with our earlier setting).
>
> Thanks again, I will inform our other teams as well doing the Solr upgrade
> to check the CHANGES.txt doc related to this.
>
