Increase gitlab.com's :diff_max_patch_bytes ~100kb -> ~200kb
Production Change
Change Summary
Historically, we've needed to closely limit the max size of a displayed diff to ensure performance and good UX. However, many users find our limits too low, and we feel that the number of performance improvements made since originally choosing the default value of 100kb will allow us to raise this minimum value to 200kb.
Change Details
- Services Impacted - gitlab.com
- Change Technician - DRI for the execution of this change
- Change Criticality - C4
- Change Type - changeunscheduled
- Change Reviewer - DRI for the review of this change
- Due Date - Date and time (in UTC) for the execution of the change
- Time tracking - Time, in minutes, needed to execute all change steps, including rollback
- Downtime Component - If there is a need for downtime, include downtime estimate here
Detailed steps for the change
Pre-Change Steps - steps to be completed before execution of the change
Estimated Time to Complete (2m)
-
Confirm availability of Source Code engineers for monitoring -
Confirm existing value of 102400
via UI (admin/application_settings/general
)
Change Steps - steps to take to execute the change
Estimated Time to Complete (5m)
-
Update value to 204800
and apply
Post-Change Steps - steps to take to verify the change
Estimated Time to Complete (15mins)
-
Observe change applied via viewing diff between 100kb and 200kb now displays -
Observe no (or acceptable) change in performance
Rollback
Rollback steps - steps to be taken in the event of a need to rollback this change
Estimated Time to Complete (5mins)
-
Update value to 102400
and apply
Monitoring
Key metrics to observe
- Metric: Overall product performance of MR pages
- Location: https://dashboards.gitlab.net/d/product-create/product-performance-create?orgId=1
- What changes to this metric should prompt a rollback:
Summary of infrastructure changes
-
Does this change introduce new compute instances? No -
Does this change re-size any existing compute instances? No -
Does this change introduce any additional usage of tooling like Elastic Search, CDNs, Cloudflare, etc? No
No infrastructure changes required
Changes checklist
-
This issue has a criticality label (e.g. C1, C2, C3, C4) and a change-type label (e.g. changeunscheduled, changescheduled). -
This issue has the change technician as the assignee. -
Pre-Change, Change, Post-Change, and Rollback steps and have been filled out and reviewed. -
Necessary approvals have been completed based on the Change Management Workflow. -
Change has been tested in staging and resultes noted in a comment on this issue. -
A dry-run has been conducted and results noted in a comment on this issue. -
SRE on-call has been informed prior to change being rolled out. (In #production channel, mention @sre-oncall
and this issue.) -
There are currently no active incidents.
Edited by Nels Nelson