Follow-up from "Definition of done: performance and availability implications of new changes"
The following discussions from !18744 (merged) should be addressed:
-
@ayufan started a discussion: (+1 comment) @smcgivern @abrandl @rymai @stanhu and anyone else interested.
Another review?
I will open a follow-up MRs that covers:
- dealing with external services,
- dealing with temporary storage,
- dealing with persistent storage.
I don't want to inflate it further at this point.
-
@mikegreiling started a discussion: (+1 comment) I think we could expound upon this paragraph slightly. This mindset really is the core of the solution – to truly consider how a feature will perform at "GitLab scale".
We need to consider "how can I break this?" when considering performance, and weigh how common that use case is against how damaging it is to performance. Usually you can use a thought experiment akin to imagining a really really large dataset. We want to optimize for the average use case, but account for the "worst case scenario" (e.g. a repo the size of the linux kernel as mentioned in the next paragraph).
This mindset is generally useful in other areas outside of performance, including security, and UX. For example, I often consider what will happen to a design element if we need to place a very large, unbroken string inside, or what if the viewport is extremely small?