#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.

10mo

Join the chat

Feb 23, 2023 (10 months ago)

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? :thinking_face:

Photo of md5-8813087cccc512313602b6d9f9ece19f

Jason

05:29 PM

CC: Kishore Nallan ^

Feb 24, 2023 (10 months ago)

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

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

10:33 AM

I get "search_cutoff": false so doesn’t seem like it

Kishore Nallan

10:33 AM

Oh :thinking_face: 😄

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

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

12:27 PM

Hmm no and in fact that last rcn62 build exactly became the GA build.

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

12:34 PM

Are the counts matching?

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

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

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

Kishore Nallan

12:51 PM

Ah yes, virtualizaation at play

Typesense

Lightning-fast, open source search engine for everyone | Knowledge Base powered by Struct.AI

Indexed 3015 threads (79% resolved)

Join Our Community

Similar Threads

Production Typesense Issue with Unexpected Filter Behavior

Ankit flagged a problem with a specific filter on the production server of Typesense. After several exchanges regarding optimisation and version checks, Kishore Nallan provided latest builds to troubleshoot. The filtering within facets issue persists and potential edge cases are being investigated.

3mo

Performance Degradation in Version 0.26.0.rc20-arm64

John and Dima reported performance decrease in version `0.26.0.rc20-arm64` of software, mainly with `group_by` queries. Kishore Nallan promised to investigate the problem.

2mo

Discussing Search API Limitations and Solutions

Sidharth had problems with search API response limitations and sorting issues. Kishore Nallan suggested multi_search query and provided links for an updated version. After installation, some timeout and performance issues were encountered, partially resolved by adjusting client timeout values.

14mo

Slow, High CPU Write Operations After Collection Drop in Typesense

Himank discussed an issue in Typesense where deleting and recreating a collection led to slow write operations and high CPU usage. Kishore Nallan suggested using an alias to avoid this issue. Numerous tests and debugging was conducted as pboros contributed with local testing. Kishore Nallan aimed to start implementing a range delete and full db compaction after deletion to potentially solve the issue.

232

17mo

Improving System Performance and Typesense Query Efficiency

SamHendley was experiencing performance issues with Typesense's large-scale system testing and proposed several improvements. Both Jason and Kishore Nallan addressed the suggestions and corrected some misconceptions. They provided further clarification and recommended upgrades for better performance.

12mo