depends on the query and your scale SpiceDB #spicedb

Join Discord

depends on the query and your scale

# spicedb

Joey

07/27/2023, 7:52 PM

depends on the query and your scale

brandon.craig

07/27/2023, 8:15 PM

Current volume is in the low hundreds per minute. The queries are pretty simple, evaluating 1 or 2 relationships.

Joey

07/27/2023, 8:15 PM

and how many nodes are you deployed on?

brandon.craig

07/27/2023, 8:15 PM

4 instances in kubernetes

Joey

07/27/2023, 8:18 PM

I'd check the following: - CPU of those nodes - Mem of those nodes - CPU of the database

Joey

07/27/2023, 8:19 PM

its possible you're overloading Aurora - SpiceDB doesn't support read replicas

Joey

07/27/2023, 8:19 PM

so its likely hitting a single Aurora node

brandon.craig

07/27/2023, 8:20 PM

I'm considering running separate read-only SpiceDB's that connect to aurora read nodes. We have a service in front of SpiceDB that would route traffic based on consistency level.

brandon.craig

07/27/2023, 8:21 PM

But thanks for the insight. I'll take a look at those metrics. If it seems like we're overloading aurora we'll want to scale up the number of aurora nodes then?

Joey

07/27/2023, 8:30 PM

likely, yeah

Joey

07/27/2023, 8:30 PM

and running a different SpiceDB is indeed an option

Joey

07/27/2023, 8:30 PM

https://github.com/authzed/spicedb/issues/1320

Joey

07/27/2023, 8:30 PM

there is also that tracking issue for having SpiceDB doing the routing

vroldanbet

07/28/2023, 1:13 PM

would also suggest using

zed

with the debug flag to understand where time is being spent. Alternatively you can use OTel tracing, which now supports granuarity down to the SQL query

vroldanbet

07/28/2023, 1:14 PM

(if you want to get the SQL granuarity in the OTel traces, I suggest getting a nightly build since it's not yet in a release)

4 Views

Previous Next