I've been unable to reproduce anything like this behavior. If you're
really getting queryResultCache hits for these, then the field
type/etc of the field you're querying on shouldn't make a difference.
type/etc of the return field (product_id) would be more likely to
matter. I wonder what would happen if you fully bypassed the query
cache (i.e., `q={!cache=false}product_type:"1"`?
I recall that previously you had a very large number of dynamic
fields. Is that the case here as well? And if so, are the dynamic
fields mostly stored? docValues?
On Fri, Jun 14, 2024 at 7:29 AM Oleksandr Tkachuk <sasha547...@gmail.com> wrote:
>
> Initial data:
> Doc count: 1793026
> Field: "product_type", point int, indexed true, stored false,
> docvalues true. Values:
> "facet_fields":{
> "product_type":["3",1069282,"2",710042,"1",13702]
> },
> Single shard, single instance.
>
> # ./hey_linux_amd64 -n 10000 -c 10 -T "application/json"
> 'http://localhost:8983/solr/XXX/select?fl=product_id&wt=json&q=product_type:"1"&start=0&rows=51'
> Summary:
> Total: 0.6374 secs
> Slowest: 0.0043 secs
> Fastest: 0.0003 secs
> Average: 0.0006 secs
> Requests/sec: 15688.5755
>
> # ./hey_linux_amd64 -n 10000 -c 10 -T "application/json"
> 'http://localhost:8983/solr/XXX/select?fl=product_id&wt=json&q=product_type:"1"&start=0&rows=50'
> Summary:
> Total: 101.3246 secs
> Slowest: 0.2048 secs
> Fastest: 0.0564 secs
> Average: 0.1007 secs
> Requests/sec: 98.6927
>
>
> 1) I've already played with queryResultWindowSize and
> queryResultMaxDocsCached by setting different, high and low values and
> this is probably not what I'm looking for since it gave a <few
> milliseconds difference in query performance
> 2) Checked on different versions of solr (9.6.1 and 8.7.0) - no
> significant changes
> 3) Tried changing the field type to string - zero performance changes
> 4) In both cases I see successful lookups in queryResultCache
> 5) Enabling documentCache solves the problem in this case (rows<=50),
> but introduces many other performance issues so it doesn't seem like a
> viable option.
