that means the DB query took 400+ms; the query det...
# spicedb
j
that means the DB query took 400+ms; the query details should be in the attributes
p
this is what i'm seeing in the attributes/events present in the trace - does this mean it took ~300ms to do the
db transaction established
step?
trying to understand what that would mean/ how i can improve that
j
likely means you had too much traffic on the node
and so it had to wait for a DB connection
p
too much traffic on the spicedb pod?
j
yes
there is a limit to the connection pool
it can be raised, but then you need to make sure your DB supports that many connections * the number of pods
p
is that configurable through the CLI args?
j
yes
p
cool, ill try to experiment with those values and see what i can work with
j
but its generally preferable to deploy more pods vs increasing the connection pool count on existing pods
p
hmm. im running 5 pods right now, the average/max CPU are fairly low (sub 10%)
RPS is in the 100-200 range (read heavy,
ReadRelationships
)
j
okay, then yeah, increase the pod connection pool size
ReadRels isn't a heavy op, but it is a longer running op
since it is streaming back all the rels found
so that means it can be holding connections longer
p
ahh. gotcha.
i also ran into some really weird behavior with ALBs on aws, i can create a new thread for that, maybe someone here would've experienced it with gRPC services - not sure if thats okay to post here
j
sure, start a new thread
I believe the recommendation is to use NLBs because ALBs can have weird effects with gRPC
since gRPC is HTTP2, but with its own quirks
p
yeah, i'd picked ALBs because AWS advertised gRPC support in them
j
oh really?
p
and it did work, just not perfectly
j
ah
j
good to know
2 Views