Ah! that's significant. The latency is likely due to building the OrdinalMap (which maps segment ords to global ords) ... "dvhash" (assuming the relevant fields are not multivalued) will very likely work; "dvhash" doesn't map to global ords, so doesn't need to build the OrdinalMap (which gets built the first time it's needed per-field per-searcher).
If "dvhash" doesn't work for some reason (multivalued fields, needs to work over broader domains, etc.?) you could probably achieve a decent result by configuring a static warming query (newSearcher) to issue a request that facets on the relevant fields. That will delay the opening of each new searcher, but will ensure that user requests don't block. SOLR-15008 _was_ actually pretty similar, with the added wrinkle of involving distributed (multi-shard) requests (and iirc "dvhash" wouldn't have worked in that case?) On Fri, Feb 5, 2021 at 8:00 PM mmb1234 <m...@vmware.com> wrote: > > Does this happen on a warm searcher (are subsequent requests with no > intervening updates _ever_ fast?)? > > Subsequent response times very fast if searcher remains open. As a control > test, I faceted on the same field that I used in the q param. > > 1. Start solr > > 2. Execute q=resultId:xxxxx&rows=0 > => 500ms > > 3. Execute q=resultId:xxxxx&rows=0&json.facet-on-resultId > => 40,000ms > > 4. Execute q=resultId:xxxxx&rows=0&json.facet-on-resultId > => 150ms > > 5. Execute q=processId:xxxxx&rows=0&json.facet-on-processId > => 2,500ms > > 6. Execute q=processId:xxxxx&rows=0&json.facet-on-processId > => 200ms > > > curl > ' > http://localhost:8983/solr/TestCollection_shard1_replica_t3/query?q=processId:xxxx-xxx-xxx-xxx-xxxxx&rows=0 > ' > -d ' > json.facet={ > categories:{ > "type": "terms", > "field" : "processId", > "limit" : 1 > } > } > > > > -- > Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html >
