Conduit support for Server-Timing headers?


Brian Smith <br...@...>
 

Kevin Lingerfelt <k...@buoyant.io> wrote:
Would it be useful for the conduit proxy to start adding Server-Timing
headers to HTTP responses?
I think there are two questions:

1. Should we support adding Server-Timing headers?
2. If so, should we add them by default?

I think it is OK to support them but we shouldn't add them by default.
From a performance perspective, the fewer headers that are sent, the
better.

Server-Timing: emoji-svc;dur=27
Server-Timing: voting-svc;dur=34.4
Server-Timing: web-svc;dur=78.1
The cluster operators likely would not want to disclose this
information in general: the names of the underlying services and/or
their performance characteristics might be private for competitive
reasons (details of performance characteristics are often guarded),
business reasons (e.g. an unreleased products' name is encoded in a
service's name), and/or security reasons (e.g. the administrators
don't want to disclose the internal topology of the cluster).

Given that this feature
requires application participation to propagate headers, it might be better
to pursue a full tracing implementation instead. But I at least wanted to
put it out there for discussion.
That's a good point. I don't think it's a matter of "instead" but it
does seem like we'd need some infrastructure for this.

I could also see a case where we'd want this to be a feature of
routing so that the headers are included, say, for developers'
requests but not for typical end-users' requests.

Cheers,
Brian
--
https://briansmith.org/


William Morgan <wil...@...>
 

Agreed this shouldn't be enabled by default. But there's potentially a cool demo we could make around this, since there is starting to be browser support for it. I suggest we keep it on the back burner until we tackle tracing.

-William

On Tue, Feb 13, 2018 at 11:50 AM, Brian Smith <br...@...> wrote:
Kevin Lingerfelt <k...@...> wrote:
> Would it be useful for the conduit proxy to start adding Server-Timing
> headers to HTTP responses?

I think there are two questions:

1. Should we support adding Server-Timing headers?
2. If so, should we add them by default?

I think it is OK to support them but we shouldn't add them by default.
From a performance perspective, the fewer headers that are sent, the
better.

> Server-Timing: emoji-svc;dur=27
> Server-Timing: voting-svc;dur=34.4
> Server-Timing: web-svc;dur=78.1

The cluster operators likely would not want to disclose this
information in general: the names of the underlying services and/or
their performance characteristics might be private for competitive
reasons (details of performance characteristics are often guarded),
business reasons (e.g. an unreleased products' name is encoded in a
service's name), and/or security reasons (e.g. the administrators
don't want to disclose the internal topology of the cluster).

> Given that this feature
> requires application participation to propagate headers, it might be better
> to pursue a full tracing implementation instead. But I at least wanted to
> put it out there for discussion.

That's a good point. I don't think it's a matter of "instead" but it
does seem like we'd need some infrastructure for this.

I could also see a case where we'd want this to be a feature of
routing so that the headers are included, say, for developers'
requests but not for typical end-users' requests.

Cheers,
Brian
--
https://briansmith.org/

--
You received this message because you are subscribed to the Google Groups "conduit-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conduit-dev+unsubscribe@googlegroups.com.
To post to this group, send email to condu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/conduit-dev/CAFewVt7DK0M0w5rA7s0cynx0FgkGpdiLdmkGXPwOv69k%3DuVxiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.