https://authzed.com logo
Powered by
spicedb
  • l

    liammoch

    05/05/2022, 12:48 AM
    To add, I am not setting GOMAXPROCS to anything specific. The spicedb container is simply what I pulled from github.
  • j

    Joey

    05/05/2022, 12:49 AM
    yeah, as stated, it defaults to the number of cores
  • j

    Joey

    05/05/2022, 12:49 AM
    so its still a limited size for that make goroutines, which means the scheduler may be getting overloaded
  • l

    liammoch

    05/05/2022, 12:51 AM
    but for that theory to hold water, shouldn't we be seeing high CPU usage for the spicedb threads?
  • j

    Joey

    05/05/2022, 12:51 AM
    not necessarily
  • j

    Joey

    05/05/2022, 12:52 AM
    in fact, with a limited number of threads available, it likely limits the amount of CPU being used
  • j

    Joey

    05/05/2022, 12:52 AM
    I suspect if you set GOMAXPROCS on your client tester to a higher number, you'll likely see higher CPU numbers
  • j

    Joey

    05/05/2022, 12:52 AM
    since it will be able to fire off the more requests at once
  • j

    Joey

    05/05/2022, 12:53 AM
    but then that generates a new issue, which is that SpiceDB is still running on the same machine, so it might be limited on handling requests as a result of contention
  • j

    Joey

    05/05/2022, 12:53 AM
    still, might be worth trying
  • j

    Joey

    05/05/2022, 12:53 AM
    a better test would be to generate a certain number of requests per second, rather than trying to fire off as many requests as possible at once
  • j

    Joey

    05/05/2022, 12:54 AM
    the former is a more realistic simulation of traffic, and if it isn't trying to run 150K goroutines at once, likely won't be nearly as scheduler dependent
  • l

    liammoch

    05/05/2022, 12:54 AM
    thanks for the inputs, will revert ...
  • j

    Joey

    05/05/2022, 12:55 AM
    I'd be curious to see what happens if you set 
    GOMAXPROCS=96
    on your test client
  • l

    liammoch

    05/05/2022, 1:09 AM
    root@887bcf1be58c:~/spicedb# export GOMAXPROCS=1
root@887bcf1be58c:~/spicedb# go run . -r 10000 -p
&{0xc0002b4500 0xc0002b4510 0xc0002b4520}
Time for sending requests 2.89180636s
Time for 150000 checks in parallel is 24.021179661s
root@887bcf1be58c:~/spicedb#
root@887bcf1be58c:~/spicedb# export GOMAXPROCS=24
root@887bcf1be58c:~/spicedb# go run . -r 10000 -p
&{0xc00037e4d0 0xc00037e4e0 0xc00037e4f0}
Time for sending requests 697.027861ms
Time for 150000 checks in parallel is 22.547278848s
root@887bcf1be58c:~/spicedb#
root@887bcf1be58c:~/spicedb# export GOMAXPROCS=96
root@887bcf1be58c:~/spicedb# go run . -r 10000 -p
&{0xc000480120 0xc000480130 0xc000480140}
Time for sending requests 828.719964ms
Time for 150000 checks in parallel is 23.099582482s
  • l

    liammoch

    05/05/2022, 1:09 AM
    "Time for sending requests" simply indicates time taken by the loop to fire all 150k go routines. "Time for 150000 checks in parallel is" indicates the time to taken for the WaitGroup to finish
  • l

    liammoch

    05/05/2022, 1:10 AM
    so no difference really to the overall time taken to complete
  • j

    Joey

    05/05/2022, 1:11 AM
    if you're using the code above, the "Time for sending requests" is, in fact, the time to kick off the goroutines, not to actually send the requests
  • l

    liammoch

    05/05/2022, 1:11 AM
    yes, the wording is incorrect. as noted in my message above it is to fire the go routines
  • j

    Joey

    05/05/2022, 1:11 AM
    yeah
  • l

    liammoch

    05/05/2022, 1:12 AM
    I suspect it's something on the server side. Would collection of metrics be helpful?
    j
    • 2
    • 26
  • j

    Joey

    05/05/2022, 1:12 AM
    tracing might provide some insight
  • l

    liammoch

    05/05/2022, 1:13 AM
    any reference?
  • j

    Joey

    05/05/2022, 1:13 AM
    the 
    --otel
    flags provide an OpenTelemetry-compliant tracing system
  • j

    Jake

    05/05/2022, 1:42 AM
    That’s an average check time of .15ms, what’s the problem?
  • s

    shubhamsinha

    05/05/2022, 5:48 AM
    Can a relation refer to the resource itself? Like this: definition test/user { relation super_admin: test/user permission get_all_company = super_admin permission create_company = super_admin }
  • j

    Jake

    05/05/2022, 10:42 AM
    Yes this will work, but you will actually have to write that relationship, and without knowing more about your use case the permissions questions that you are able to ask seem weird
  • j

    Jake

    05/05/2022, 10:43 AM
    What does it mean for a user to be a super admin of another?
  • j

    Jake

    05/05/2022, 10:44 AM
    This blog post talks about how to model super admin: https://authzed.com/blog/schema-language-patterns/
  • w

    williamdclt

    05/05/2022, 2:00 PM
    It would be very useful to have a way to define a permission as a constant, not referring to any permission (something like 
    permission view = user:*
    , all users have this permission or none do). This is important for us for backward-compatibility: we have features that are released to a beta group (using a 
    beta
    flag in SpiceDB), before being rolled out to everybody. Once it's rolled out we'd like to get rid of the 
    beta
    flag, but in the meanwhile we need to continue to have the 
    view
    permission in spicedb for backward compatibility
1...140141142...325Latest