I've long wanted something to start a timing context when a request is started, whether that be when a connection is initiated or when the verb+URI is received on a persistent connection. We've never had the ability to include queued time in our latency measurements, which means you could have requests sitting in the inbound queue for a relatively long time but completing in a relatively short time.
It'd obviously be more complicated to capture this information. We might have to plumb pretty deep into Jetty to get at it. But then we could generate more complete timing data and begin providing breakdowns around stuff like time spent in the queue, time spent deserializing, time spent waiting for bytes to be sent/received, etc. If all we want is for timing to start including deserialization, however, we might just look at DefaultServerFactory and its siblings: https://github.com/dropwizard/dropwizard/blob/3ddb4a92b53e515609ab39c3ba228387b7ccaf61/dropwizard-core/src/main/java/io/dropwizard/server/DefaultServerFactory.java#L154-L181 As far as I can tell, the reason we don't include gzip time is that createAppServlet() returns the InstrumentedHandler, which DefaultServerFactory wraps in the routing handler and the gzip handler. So the gzip handler sits "around" the timing in the InstrumentedHandler. If we restructured it so the InstrumentedHandler sat "around" the gzip handler, it would start including that timing data. A big question then becomes whether we'd want to keep the current timing metrics to indicate (more or less) how long request processing took and have separate metrics for something closer to an all-inclusive, caller-perceived request time. Ryan On Mon, Aug 1, 2016 at 8:42 PM, Evan Meagher <[email protected]> wrote: > I ran into this a while ago too. Unfortunately, the resource > instrumentation afforded by the metrics library is downstream (i.e. later > in the request lifecycle) than the Jetty handler which deals with gzip > serialization. AFAICT there isn't an out-of-the-box means of measuring > request latency including [de]serialization. > > It would be pretty straightforward to have Dropwizard's BiDiGzipHandler > emit measurements of request-handling latency from its perspective. This > could be made configurable via a new option under server.gzip > <http://www.dropwizard.io/1.0.0/docs/manual/configuration.html#gzip>. > > Happy to put together a PR if others think this could be useful. > > On Mon, Aug 1, 2016 at 5:44 PM, Alex Yakushev < > [email protected]> wrote: > >> Hi, >> >> We're using @Timed annotations for metrics, which work great, except >> they don't seem to include serialization. Is it possible to time the entire >> request, not just the resource portion of it? >> >> Thanks, >> >> Alex >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dropwizard-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Evan Meagher > > -- > You received this message because you are subscribed to the Google Groups > "dropwizard-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
