Closed milesrichardson closed 1 year ago
OK, after flailing around in Warp and it's world of Filter
s, I ended up switching gears and now added an explicit timer inside cached_read_query
/uncached_read_write_query
.
It's very simple and not yet DRY'd but wanted to push this up as a PoC of 'whole request' timing.
Probably whether Seafowl returns this header should either be 1) configurable or 2) perhaps it should follow warp::trace::request()
's footsteps and return only at INFO/DEBUG level. Or maybe both. (?)
Thoughts?
Closed by #438
Related: #356
Feature Request
It would be nice if the response from Seafowl included some information about execution time in the response headers. Currently, a client has no insight into execution metrics, other than measuring the total round trip time of the request and response.
Motivation
Having access to more timing data would be helpful for diagnostics, and for writing interactive query tools similar to the Splitgraph Query Console. For example, the Splitgraph DDN provides fields
executionTime
andexecutionTimeHighRes
, which represent the time spent by the Splitgraph Engine "processing the query," which, in effect, is the interval defined by the boundaries where the "DDN web bridge" stops reading the HTTP request, and when it starts writing the HTTP response.Open questions:
What should be measured?
How should it be returned in the response headers?
All considerations from https://github.com/splitgraph/seafowl/issues/356#issuecomment-1505759519 apply:
parameters
of theContent-Type
header, similarly to how we might return the field types. (The advantage of this option is thatContent-Type
is a default CORS-safelisted HTTP response header.)For the
content-type
option, perhaps any non-field metadata could be in parameters conventionally prefixed with__
, e.g.: