Gray
CCConvex Community
•Created by Gray on 10/26/2023 in #support-community
What to expect from built-in query caching
As I mentioned in another post yesterday, I am curious to know more about the behavior of Convex's built-in query caching. My main question is about the extent to which it's advisable to rely on the built-in caching to achieve a desired level of performance.
Like my function-profiling question, this one has become less pressing because my app's critical query is now running fast enough that I'm not so concerned about cache misses, but I'd still like to get a better understanding of caching behavior and best practices.
Specifically, I'm wondering under what circumstances a cached query might be evicted from the cache without any changes to the query's code or the data it depends on. Is there any behind-the-scenes logic that evicts less frequently / recently used queries? If so, does that run per-instance, or might a less heavily used instance's cached queries be evicted to make room for another instance's entries? In a similar vein, are there things that might cause the cache to be cleared entirely?
In my app, data is read much more frequently than it is written, and the same queries are likely to be requested from different clients, so in a world where the cache weren't actively managed or periodically cleared, I'd expect a very high hit rate. When I was looking at a significant discrepancy between cached and uncached performance, though, I was nervous about relying on cache hits and considering whether I might need to implement some bespoke, app-level caching to ensure consistently good performance.
7 replies
CCConvex Community
•Created by Gray on 10/25/2023 in #support-community
Profiling function performance
I have an app that I'm aiming to move from Firebase to Convex. Functionality-wise, the migration is nearly complete.
The Convex version is nicer in every way and there are a bunch of features I'd like to add that I expect will be much easier to implement with Convex than with Firebase.
Before committing, though, I'm trying to satisfy myself that the Convex version of the app will be viable from a performance and cost point of view. I've got a handful of specific questions, which I'll try breaking up into separate support threads.
My app essentially presents a large data set and provides affordances for zeroing in on items of interest via tag-based filtering. The Firebase version, out of necessity, does a lot of manual preprocessing, computing the items returned for combinations of tags and storing them in the database. In the Convex version, I'm hoping to avoid that, instead relying on Convex's close-to-the-db backend logic and query caching to yield good performance while keeping the implementation much simpler.
I'll ask caching questions in another thread, but first I'm wondering if there's any guidance on doing fine-grained performance profiling within a function. My current implementation features highly normalized data; the query driving the main view loops through the base data set, does per-item db reads to retrieve tags, filters items by tag, and finally loads additional fields for the filtered items. Performance in the uncached case is borderline acceptable. I can think of ways to improve it, mainly via different flavors of denormalization, but before going down the path of trying these, I'd ideally like to collect some data on where my execution time is currently being spent.
My naive attempts to collect / log timing data have been thwarted by the limitations of the runtime that guarantee deterministic query execution. Is there any alternative?
10 replies
CCConvex Community
•Created by Gray on 10/25/2023 in #support-community
`ConvexClient` questions
I was happy to see
ConvexClient released and I recently swapped it into a couple of lightweight integrations I'd previously done with Preact Signals and Lit Reactive Controllers, replacing a similar "generic" reactive client I'd built myself on top of BaseConvexClient. ConvexClient ended up being more or less a drop-in replacement, which was great!
Having tried it out, I do have a couple of observations / questions; they aren't really support things, per se, but this forum channel seemed like a good spot to raise them.
1. My own client had support for optimistic updates, patterned after (and borrowing types from) the React client. I see that ConvexClient doesn't have optimistic-update support; I can imagine a few reasons why that might be and am curious to know what the actual one(s) are.
2. FYI, when I was doing my Preact Signals integration, I ended up adding a configuration option to my reactive client allowing the equivalent of ConvexClient's _transition() method (where callbacks are invoked) to be wrapped in a developer-provided function. This was so I could use Preact Signals' batch() function to optimize signal performance in the case where multiple Convex queries updated at once. I unfortunately no longer have the simple test cases I was using that led me to conclude this was necessary / desirable, but could probably reconstruct them.6 replies