Hey. I'm running the latest typesense server with the php client since a few days. More than half of the queries are the same, so most of the queries could come from cache. Caching is enabled (in multisearch->perform()), but the CPU usage is suspiciusly high (8 vcpu and ~500k docs (this is a sum of all docs in multiple collections), 100reqs/sec). Latency is OK. Can you recommend me something to figure out the cache hit/miss ratio maybe? Or how could I debug this? For sure I could put memcache in front of typesense but I would avoid it if I can.

Hi Zsolti, debugging and figuring out why the CPU usage is so high is a must, but, if it turns out that this is a normal behavior I would recommend using CloudFlare in front of typesense especially if the change velocity of your quries/data is farily static.

So basically I should not trust the use_cache feature ? :) I inserted a very simple memcache in front of the typesense calls, and it reduced the queries per second from 100 to 30, so there was something wrong with the typesense cache.

if you're just fetching all documents, your database is probably going to beat typesense

Thank you.

@Zsolti Typesense's query cache implementation is currently pretty conservation: we cache only 128 query responses and start evicting the oldest inserted element when the cache capacity grows past 128 entries. The default cache TTL is also only 60s. This might explain why the caching does not seem to have much impact. We plan to make the cache size configurable. As for the

q=*

queries, Typesense is slower because we haven't yet optimized it for this use case. It does a couple of dumb things that the moment, which we again want to fix in future. But again this should be cacheable if the cache is large enough.

Hi @Zsolti, I haven't said that you don't have to rely on Typesense cache, but, it's better to use the right tools for the right job, as you have seen the memcache implementation did the job. And, @Kishore Nallan explanation is proving my point.

Thanks for the explanation !