commit 2a10f895b94a193397daeb6caca6d28e778258a0
author Edwin Kempin <ekempin@google.com> Fri May 24 08:43:44 2024 +0000
committer Edwin Kempin <ekempin@google.com> Fri May 24 09:32:22 2024 +0000
tree 3b6edd6a9b91f0b3063dc319ddffa1b15d345541
parent 74de9b58d8eab119350e03dd8c6311595b4fe4ee

Add experiment flag to disable change etags

Etags help to avoid unnecessary recomputation of responses, e.g. for
changes we compute an etag, and when the client presents this etag and
the change hasn’t been updated, we do not need to recompute the change
info, but we can return '304 Not Modified'.

Etags work well when they are cheap to compute, but that’s not the case
for our change etags. To give one example for what makes the change etag
computation slow, we include the known groups of the current user to
ensure that the etag changes when the group memberships of the current
user change, because that may impact the permitted labels that are
returned with change info, and getting the known groups is expensive if
there are group backends that need to retrieve them from third-party
systems (actually the same issue exists for the reviewers as well since
permitted labels are also returned for them, but for them we do not
include known groups).

Etags need to be computed when a response is returned (to include the
etag into the response) and when the client presents an etag (to check
whether the etag has changed).

Skipping the etag computation means that we can safe the time for
computing the etag, in exchange for this we need to recompute the change
info even if the change hasn't been updated (when the client presented
an etag and the etag hadn't changed):

1. Change is requested without presenting an etag:
* latency before: change computation + etag computation (to return it
  with the response)
* latency after: change computation

2. Change is requested with etag, but the etag doesn't match:
* latency before: etag computation (to compare against the presented
  etag) + change computation + etag computation (to return it with the
  response)
* latency after: change computation

3. Change is requested with etag and the etag matches:
* latency before: etag computation (to compare against the presented
  etag)
* latency after: change computation

Skipping the etag computation is a performance gain for the cases 1. and
2. For case 3. the change computation is likely similar expensive as the
etag computation, so that we probably don't lose (much) performance
here.

Since we are not 100% sure about the effect, we protect skipping change
etags with an experiment flag, so that we can measure the impact safely
before removing the change etag computation for good.

Bug: Google b/336400432
Release-Notes: skip
Change-Id: Ib1ca473180d930c3cea0ade3b528ece34f295b5a
Signed-off-by: Edwin Kempin <ekempin@google.com>