You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our system, we have "projects" which a user can view and "clips" which a user can view. If a clip is in a project, then the user can view the clip transitively. This works fine when a clip is in a very small number of projects, but if a clip is in ~200 different projects, then it slows down to >1s to check if the user can view the clip.
Running Keto locally, it appears to be churning through requests against SQL, loading every relationship into memory before checking if the user has access to any of them.
After some more digging, the main problem here seems to be the breadth-first search in checkExpandSubject. It grabs every Project tuple from the DB and then it starts looking through each one for the user. Then each lookup is a separate query which has it's own round trip time. Which explains why it's so much slower in a real database.
Could switch from a breadth-first search to a depth-first search. In this case the relationship chain we're trying to find is: Clip -> Project -> User, so by enumerating all the Projects first we always get worst-case time.
There's also a lot of chattiness between the container and the DB, so if more work could be offloaded to the DB it could make a big difference. This seems like a really good use-case for Postgres's WITH RECURSIVE clauses, although the current implementation seems to be independent of particular SQL versions https://www.dylanpaulus.com/posts/postgres-is-a-graph-database
Preflight checklist
Ory Network Project
No response
Describe the bug
In our system, we have "projects" which a user can view and "clips" which a user can view. If a clip is in a project, then the user can view the clip transitively. This works fine when a clip is in a very small number of projects, but if a clip is in ~200 different projects, then it slows down to >1s to check if the user can view the clip.
Running Keto locally, it appears to be churning through requests against SQL, loading every relationship into memory before checking if the user has access to any of them.
Reproducing the bug
Permissions model:
Create 200 relationships of different projects all pointing to the same clipId, make a user an owner or editor on any one of the project.
Check if the user can access the clip
Expected: The query to still be fairly fast <50ms
Actual: On an M2 Mac with SQLite >150ms, but on a real database deployed in a container can take >1s
Relevant log output
No response
Relevant configuration
Version
v0.12.0
On which operating system are you observing this issue?
macOS
In which environment are you deploying?
Docker
Additional Context
No response
The text was updated successfully, but these errors were encountered: