Skip to content

Some standards we can use to clarify what we mean by performance

Ernst van Nierop requested to merge evn-more-fe into master

I feel that something like this is necessary since we have different goals / ways of speaking about performance in different parts of the handbook.

For instance, if this MR has support, the next step would be to refer to this section from https://about.gitlab.com/handbook/product/#performance which lists target time to first byte (TTFB) to be 1 s for new pages, 2 s as the limit for old pages, 5 s as totally unacceptable. That's helpful, but skips all the frontend stuff.

Similarly, in the OKRs we list:

  • CEO: GitLab.com ready for mission-critical tasks. 99% of user requests < 1s
    • VP Scaling: Lower latency. 99% of user requests < 1 second
    • VP Eng: Lower latency in application
      • Discussion: Solve performance issues. Reduce p95 of discussion-related actions with over 10 hits/day to < 1 s. Reduce p99 to < 3 s.
      • Platform: Solve performance issues. Reduce p95 of platform-related actions with over 10 hits/day to < 1 s. Reduce p99 to < 3 s.

but we don't quite specify there what time is being measured... TTFB? Full load time? Etc.

Then finally, in my first attempt at clarifying that, I at one point added this to the infrastructure handbook: https://about.gitlab.com/handbook/infrastructure/#infrastructure-teams

GitLab.com's performance.

  • Current goal: 99% of user requests < 1 second
  • Latency here is currently measured via the "Transaction Timings" dashboard linked above. Those timings only represent part of the web request processing time but are well-defined.

Those "transaction timings" are not equal to TTFB, since they are internal to the backend.

So I'd propose that we set targets as specified here: one for overall user experience basing it on sample pages, and then separate (lower) targets for backend with a little bit of network latency to get TTFB.

We still need to specify a network speed; or just live with whatever is "native connectivity" from the DO boxes that we run our Blackbox monitoring on.

\cc @JobV @sytses @stanhu @jschatz1 @timzallmann @sitschner @pcarranza

Merge request reports