https://authzed.com logo
Join Discord
Powered by
lots of people. see https://github.com/authzed/spi...
# spicedb
j
f
this issue mentions that
Copy code
Various tests show approximately ~100ms for a LookupResources call on a SpiceDB with 100-250K relationships, and a graph nesting of 3-5 deep.
Do you guys have any reference benchmarks tests available to check out? Can't get anywhere close to this, curious what the nature of this 
LookupResources
request was - - how many resources were returned, what the schema was, etc
j
only the ones defined for point benchmarking
it will heavily depend on your schema
if you use intersections, exclusions or caveats, for example
then we have to issue post-reachable checxks
which vastly slows things down
f
kk thanks
j
we're working on adding cursoring to LR to reduce the overhead
but realistically, it depends highly on what your model is and what your use case is
that's why WatchLookupResources is a proposal
f
can you point me to the benchmarking set up? Would like to compare the reference schema / dataset to my own.
j
as stated above, its for point benchmarking
its mostly unit tests for benchmarking very specific scenarios and will absolutely not reflect real data shapes
the reference data set has maybe 10s of relationships
f
thank you! The issue above mentions
Copy code
Various tests show approximately ~100ms for a LookupResources call on a SpiceDB with 100-250K relationships, and a graph nesting of 3-5 deep.
so I was ideally looking that dataset. I have a similar data cardinality and only two levels of nesting and seeing ~2seconds for lookupResources, no exclusions, etc
j
sure
that was a manual test we ran many, many moons ago
you'll have to look at an OTEL trace to see how its running on your specific data set
after all, its possible you're trying to return a very large number of results
the above manual test was 100-250K relationships, but only 10s of results max
f
I see
yeah, trying to return 100k+ results
j
oh yeah
that's almost certainly the reason then
what do you intend to do with 100k+ results?
f
haha. well, I'm trying to solve ACL filtering on LIST apis. one of the ways I was hoping to test is loading in all entities and do some post-filtering
j
I suspect at that scale, you'll want to find the items in your DB first and then check them
we're working on adding cursor support to LookupResources now
so rather than trying to load 100k+ results at once, you'll be able to stream them more efficiently
f
yeah that would work too
j
would you be able to share your schema and over which permission you're invoking the LR call?
f
definitely
will send you the schema without exclusions, and with. the problem with exclusions is a lot gnarlier
j
yeah, exclusions will make things slower
f
yeah makes sense. I'm learning more about how things are implemented
j
but we have a number of improvements (like cursors) coming to LR to make this much more manageable
f
cool. yeah been trying to figure out this ACL filtering problem, its tough. Doing post filtering via issuing a bunch of CheckPermissions calls after reading from DB works but is slow, doing post-filtering via precomputing full set of Resources via LookupResources is slow/clunky, and replicating some permissions data from SpiceDB into main datastore isn't trivial (we will be serving LIST apis out of elastic search, so we'll need to build some kind of system leveraging Lookup Watch API and stuff list of authorized users into objects indexed in Elastic)
j
yeah, that's why https://github.com/authzed/spicedb/issues/207 is a proposal to allow for easy replication
it was designed with ES in mind
in theory
f
nice. yeah the checking permission after loading is correct but has bad pathologies where authorized rows are scanned last from the DB. issue 207 would be sweet.
PreviousNext
Powered by