Do you really have 96 separate disks and memory for each shard? They seemed a bit small and numerous to me, unless you are trying to fit every shard into memory of separate nodes and have the hardware resources for it
— > On 19 Apr 2023, at 05:43, Rajani Maski <rajinima...@gmail.com> wrote: > > It is a query with popularity and recency boosts, requesting the first 100 > docs with 3 fields per doc. No facets. It is a query against a collection > of 96 shards ~7m docs per shard. Could the cause for latency be boost > queries and would it also be time spent in aggregating results from many > shards? Curious to learn more about caching such/short queries that @Mikhail > mentioned. > >> On Tue, Apr 18, 2023 at 9:44 PM Dave <hastings.recurs...@gmail.com> wrote: >> >> I think there are more important questions here. What do you want with a >> *:* query? Do you want all the results in on return? Or do you just want >> the count of total documents? Or to put the results in facets? *:* should >> never take long unless you are requesting every single document not just >> the first ten. >> >>> On Apr 18, 2023, at 9:05 PM, Rajani Maski <rajinima...@gmail.com> wrote: >>> >>> Hi Mikhail, >>> >>> Yes, 9.1.1, that should be helpful, can you please point me to the >>> related jira(s) and/or docs? >>> >>> Thank you, >>> Rajani >>> >>> >>> >>>> On Mon, Apr 17, 2023 at 2:09 AM Mikhail Khludnev <m...@apache.org> >> wrote: >>>> >>>> Hello Rajani. >>>> Which version are you running? IIRC 9.1.2 has some >>>> improvement about caching short queries. >>>> >>>> On Sun, Apr 16, 2023 at 4:25 PM Rajani Maski <rajinima...@gmail.com> >>>> wrote: >>>> >>>>> Hi Solr Users, >>>>> >>>>> What are your suggestions to improve star queries latencies? By star >>>>> queries I mean "*:*" or single term queries having boost formulas >> (such >>>> as >>>>> doc recency and many others) taking 10 or more seconds. It is a large >>>>> collection with good compute resources, however I am guessing this may >> be >>>>> because each shard has too many documents and I noticed per shard >>>> response >>>>> time also is high. >>>>> >>>>> Splitting shards could be an option however it is already an >>>>> evenly distributed, composite router, 96 shards collection, I am >>>>> concerned that more than 100 shards per collection can lead to >>>> exhaustively >>>>> searching too many shards and aggregation issues. What are your >> thoughts? >>>>> >>>>> Can we make use of any caches, query result cache or other caches, in >>>> solr >>>>> that allows warming up and persisting these queries results in ram, and >>>>> that maybe helps reduce this query time? >>>>> >>>>> Thanks, >>>>> Rajani >>>>> >>>> >>>> >>>> -- >>>> Sincerely yours >>>> Mikhail Khludnev >>>> https://t.me/MUST_SEARCH >>>> A caveat: Cyrillic! >>>> >>