#community-help

Slow Performance of Faceted Query with Increased Fields

TLDR John experienced slowdown in faceted queries after increasing to 1000 fields. Upgrading from 0.24.0.rcn21 to 0.24.0 improved performance. The issue was attributed to John using an ARM build on an M1 Mac.

Powered by Struct AI
grinning1
sweat_smile1
thinking_face1
20
7mo
Solved
Join the chat
Feb 23, 2023 (7 months ago)
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
04:32 PM
Hey, we have a collection with thousands (!) of fields per document where we select only a few fields at query time depending on the user. It used to have O(100) fields and performance was fine, but faceting seems to be very slow now that we have O(1000) fields and I’m trying to wrap my head around it. Do you see any reason why this should be the case? I figured that only indexing would be slow with many fields and runtime performance unaffected.

Before: ~100 fields, faceting by 8 fields with max_facet_values=100 => ~0.3 seconds
After: ~1000 fields, faceting by 8 fields with max_facet_values=100 => ~1.5 seconds (without faceting ~0.08 seconds)
04:34
John
04:34 PM
Maybe it’s fetching the entire documents somewhere and the documents are huge so it’s slow? 🤔
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
05:29 PM
CC: Kishore Nallan ^
Feb 24, 2023 (7 months ago)
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
10:29 AM
Hmm, I upgraded from 0.24.0.rcn21 to 0.24.0 and got a dramatic speed-up, from 1300 ms to 140 ms, almost suspiciously fast 😄 I’ll have to look into it a bit more, but maybe there was some major change to facet computation since rcn21
Kishore Nallan
Photo of md5-4e872368b2b2668460205b409e95c2ea
Kishore Nallan
10:32 AM
👋 Check if the default search cutoff is happening (look for the search cutoff boolean field in the response).
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
10:33 AM
I get "search_cutoff": false so doesn’t seem like it
Kishore Nallan
Photo of md5-4e872368b2b2668460205b409e95c2ea
Kishore Nallan
10:33 AM
Oh 🤔 😄
10:34
Kishore Nallan
10:34 AM
Then it's possible that some performance improvement has landed. We are always working on a stream of perf work so that's possible.
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
10:38 AM
Let’s hope that’s the case 😄
12:24
John
12:24 PM
It’s slow on 0.24.0.rcn62, which is the latest nightly build before 0.24.0, and fast on 0.24.0. Very strange. Is there something different about the nightly builds that could cause it?
Kishore Nallan
Photo of md5-4e872368b2b2668460205b409e95c2ea
Kishore Nallan
12:27 PM
Hmm no and in fact that last rcn62 build exactly became the GA build.
thinking_face1
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
12:32 PM
It’s again slow on later builds like 0.24.1.rc4 so there’s something special about the 0.24.0 I’m running 😄
Kishore Nallan
Photo of md5-4e872368b2b2668460205b409e95c2ea
Kishore Nallan
12:34 PM
Are the counts matching?
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
12:37 PM
The facet counts are not matching but in the same ballpark, and
Fast (search_time_ms=130): found=1102, out_of=5800
Slow (search_time_ms=1361): found=945, out_of=2053
12:37
John
12:37 PM
search_cutoff=false for both
12:39
John
12:39 PM
My 0.24.0 image is larger than all the rest for some reason, it’s 926MB while all others (both before and after) are 789-798MB
Kishore Nallan
Photo of md5-4e872368b2b2668460205b409e95c2ea
Kishore Nallan
12:40 PM
This is very strange. All images are built in the same way and there has not been any changes in the build process until we cut the 0.24.0 release.
12:41
Kishore Nallan
12:41 PM
Is it possible for you to reproduce on another machine or with the Linux binary for the 0.24 release?
John
Photo of md5-21545f1facb7836c149bc4c70752bd2b
John
12:51 PM
Ahhhh it turns out it’s because 0.24.0 has an ARM build and I’m on a M1 Mac, whereas the others are just AMD64
grinning1
sweat_smile1
Kishore Nallan
Photo of md5-4e872368b2b2668460205b409e95c2ea
Kishore Nallan
12:51 PM
Ah yes, virtualizaation at play