Help reducing latency for lookup-resources
# spicedb
Hello all, I've got a question about optimizing a model for more efficient lookup-resources. Currently we expose an endpoint that frontend apps can use to list resources that a user has access to, which internally relies on lookup-resources. The problem is that we get high latencies (before any caching happens). Even just using
(bypassing our endpoint logic), something like
zed permission lookup-resources project read user:2
takes about 10s (even if the user doesn't have access to any resource) which is not ideal when it's needed to load a web page. Here is a simplified version of our schema: (I tried to keep only stuff related to the read:project permission, for this specific example, but could share the whole schema if it can help). We use intersections and synthetic relations heavily, not sure if those impact latencies. We are looking for general advice on how to improve/simplify our model, or any other advice on what could help reduce latencies of lookup-resources. Thanks!
Intersections require a post filtering check on our side
So they definitely impact performance
We have plans to address that but long term, the solution will likely be to use our proposed watch API
I see, thanks. Could you share some docs on how best to use the Watch API and how it would help, I couldn't find much online. Also regarding the long term vision, are you referring to something like this:
yes, that's the analogue to the leopard cache that zanzibar uses for the same use case
The lookup resources watch API would be provided in that proposal
I see, so with the current capabilities of spicedb, what would be the recommended way of improving the latency of our use case? Is it just continuing to use the lookup-resources API and try to minimize intersections in our schema?
right now, even a single intersection (or exclusion) will requires results to be check'ed
so unless you can completely remove them, it won't appreciably change performance
Ah okay, got it, thanks. So basically, right now there's not much to be done to improve performance when trying to list all resources a user has access to.
Do you guys have a rough timeline for when the long term improvements will be implemented?
hence long-term 🙂
we're still discussing the exact set of improvements to make
Sounds good, thanks for confirming.
in the interim
if you have an intersection
and you know one branch is cheaper to compute
put it first in the intersection
i.e. if you know it'll produce much smaller result sets
that can significantly cut down on the check times
I'll try that, thanks for the suggestion.