Check out performance metrics and back-calculate gains needed
- We state that we wish to reach 99% of user requests to be < 1 second.
- We have metrics on monitor.gitlab.net which show the # of times a Rails controller is called, the p50, p95, and p99 of the time it took to execute it, and various other metrics.
- The Gitaly team is tackling the controllers that represent git actions one by one, in order of largest (count x p99 time).
- Document how to make dashboards #1876 (closed)
- Analyze transaction time and correlation with rails controller time #1877 (closed)
- Sketch flow from web request to fully completed request, highlight what is monitored. #1878 (closed)
- Gather monitoring data for longer time periods #1879
- Allow more GitLab internals monitoring https://gitlab.com/gitlab-org/gitlab-ce/issues/28465
- Analyze reasons for performance difference on two issues, as case study #1880
- Understand our blackbox monitoring in more detail #1881 (closed)
- Profiler is great, do we need anything else? #1882 (closed)
- Run a test with more app servers? #1883 (closed)
- CDN #57 (closed)
- Scoping work on speeding up DB queries https://gitlab.com/gitlab-org/gitlab-ce/issues/33726
- Overview of top 10 slowest queries https://gitlab.com/gitlab-org/gitlab-ce/issues/34535
- Scoping work on completing the transition to Gitaly gitlab-org/gitaly#313 (closed)
- Making workhorse timings available https://gitlab.com/gitlab-com/infrastructure/issues/2025
Taking https://about.gitlab.com/handbook/engineering/performance/#flow-of-web-request and putting it in spreadsheet form, world viewable and GitLab editable.
We're working in a Google Doc. This document is world viewable at https://docs.google.com/document/d/1vP0wgmXNwbDviCrN5HLbSYMpnQU5lELsq9Hdn80bZvc/pub and you can edit it at https://docs.google.com/document/d/1vP0wgmXNwbDviCrN5HLbSYMpnQU5lELsq9Hdn80bZvc/edit if you're a GitLab team member.