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 <kerwin...@gmail.com> 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. >