https://authzed.com logo
Join Discord
Powered by
schema discussion
# spicedb
l
we have 51 subscription-plans, and roughly, there is one plan with 110k subscriptions
j
and you're checking for 
user
?
so one plan could have 110k subscriptions?
i.e.
l
yes we're checking
Copy code
zed permission check channel:channel_id view user:user_id
j
subscription_plan#subscriber
has 110K relationships?
yeah, that's the issue
l
you could see the plan 
bb3d13a6-7c78-408e-aea3-a77a7619379f
has 114k
j
if it was 
subscriber: user
then SpiceDB could directly check "find me if this specific user exists"
but because it has to walk through 
subscription#subscriber
it has to check all 110K of those
the new query planner has code to "reverse" this kind of wide relation
but its still experimental
you can likely improve things massively by changing the default dispatch size
l
Yes, I think it'll be better if we start from subject side, not from the resource side in this case
j
it is 
100
by default: try changing it to 
1000
that will mean running 100 checks instead of 1000
l
Copy code
the new query planner has code to "reverse" this kind of wide relation
Yes I've seen it on the page, v1.51.0 support it sir?
Copy code
apiVersion: authzed.com/v1alpha1
kind: SpiceDBCluster
metadata:
  name: prd-spice-db
  namespace: appauth
spec:
  secretName: spicedb-config
  config:
    datastoreEngine: postgres
    enableRevisionHeartbeat: "false"
    httpEnabled: "true"
    image: authzed/spicedb:v1.51.0
    logLevel: "trace"
    replicas: "3"
    skipReleaseCheck: "true"
  patches:
    - kind: Deployment
      patch:
        spec:
          template:
            spec:
              containers:
                - name: spicedb
                  resources: 
                    requests:
                      cpu: 500m
                      memory: 512Mi
                    limits:
                      cpu: "1"
                      memory: 1Gi
                  args:
                    - "serve"
                    - "--experimental-query-plan=check"
                    - "--log-level=trace"
I added the flag to my specs, but seems like there still bug with that one.
j
I'd highly recommend not using it yet
its very early
I'd make the dispatch chunk size change instead
the reversal optimizer is not enabled yet
l
I'll try but there if distribute the work by increasing the number of dispatcher, there is still work with the plan that has 110k subscribers, so still bottleneck with that.
Also, I noticed in the code that the cache key includes subject information, so two users on the same plan can't reuse the cache. For example, userA and userB both checking for the same channelX — the path only differs from user -> subscription -> plan, while the rest from plan -> channel remains the same.
j
it decreases the number of dispatches
the chunk size increases the work each dispatch does
and of course: because the cache is the subproblem
userA might have access and userB might not
l
I know I'm very early to the codebase but if two checks for two users, share the same path on the graph, we might re-use the result somewhere (at least in case the schema did not declare any caveat). I'll dive more on this 😄
j
they can only share a path if they... shared a path
by definition, they can't share a path because the path ends at different users
remember: userA might be part of one subscription and userB part of another
so the path sharing would be minimal/non-existent
l
ah now I know, Im thinking in 
user -> resource
perspective. The code works in 
resource->user
j
correct
now, once query planner supports reversal
yes, the common portion will be cached
l
yep, waiting on this, thanks for the support.
12 Views
PreviousNext
Powered by