4 ms·
Why not call this SupaPool? Supavisor is very BEAMie. Question about telemetry. These are the metrics emitted by Ecto: - :idle_time - the time the connec
by Dowwie 4y ago
Why not call this SupaPool? Supavisor is very BEAMie.
Question about telemetry.
These are the metrics emitted by Ecto:
- :idle_time - the time the connection spent waiting before being checked out for the query
- :queue_time - the time spent waiting to check out a database connection
- :query_time - the time spent executing the query
- :decode_time - the time spent decoding the data received from the database
- :total_time - the sum of (queue_time, query_time, and decode_time)
To what extent are these metrics distorted by use of a Supavisor connection pooler? How could Supavisor compensate for that?
- chasers 4y agoIt is very BEAMy because we love the BEAM. All connections are supervised :D Might be a little too close to "supervisor" though. > To what extent are these metrics distorted by use of a Supavisor connection pooler? How could Supavisor compensate for that? You mean if you have an Elixir app and using Supavisor for connection pooling? They would be affected as much as they would be if you used PgBouncer. For the metrics Supavisor is exposing, it has those Ecto metrics for the interactions with the management database. Supavisor doesn't use any libs for handling the wire protocol. It handles the wire protocol directly. We are exposing some similar ones: https://github.com/supabase/supavisor/wiki/Metrics https://github.com/supabase/supavisor/wiki/Metrics