You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Server-Timing currently conflates the pool checkout time with the transaction time. Meaning we cannot differentiate if a query took a lot of time or if acquiring the connection from the pool did.
Solution
Add a pool-checkout duration:
HTTP/1.1 200 OK
Server-Timing: jwt;dur=14.9, parse;dur=71.1, plan;dur=109.0, pool-checkout;dur=10.3, transaction;dur=353.2, response;dur=4.4
Notes
Measuring check-in time (time to return the connection to the pool) doesn't make much sense in our case IMO, since we always return the connection right after finishing the transaction. This probably makes more sense in traditional three-tier apps where some business logic is done in the application layer while a pool connection is being used.
The text was updated successfully, but these errors were encountered:
So while we could have a Metric (o new Observation) inside the pool, is not straightforward to get it out. Maybe we could use an IORef there, but it's kind of messy.
Problem
Server-Timing currently conflates the pool checkout time with the transaction time. Meaning we cannot differentiate if a query took a lot of time or if acquiring the connection from the pool did.
Solution
Add a
pool-checkout
duration:Notes
Measuring check-in time (time to return the connection to the pool) doesn't make much sense in our case IMO, since we always return the connection right after finishing the transaction. This probably makes more sense in traditional three-tier apps where some business logic is done in the application layer while a pool connection is being used.
The text was updated successfully, but these errors were encountered: