Skip to content

Enable pagination in the CompareController

What does this MR do?

Enables pagination in the Projects::CompareController.

Previously, the pagination in the Projects::CompareController was disabled by default. It leads to memory usage bloat.

We enable it and set it to a rather aggressive (low) value, unlike it is in the CommitsController (which is currently 75).
This MR also adjusts the per-page amount of items we show in the CommitsController: 75 -> 20, to be same with the CompareController.

When we paginate, we render the commits section only on the first page in the CompareController.

Screenshots

Screenshot_2021-04-13_at_16.57.51

The effect

It reduces the mem_bytes values (described in the https://docs.gitlab.com/ee/development/performance.html#checking-memory-pressure-of-own-code) from ~500 MB to ~200 MB on GDK, for this example: http://localhost:3000/gitlab-org/gitlab-shell/-/compare/gitaly-post-receive...181-authorized-keys-check-go .

The note about the results & the data

The memory usage of this endpoint entirely depends on the data it renders, in our case - the amount of the diffs/commits added between two branches.

It could be as small as just rendering our usual layout (if there is nothing in the diff), and as large as it could probably take until getting shut down by the Puma OOM killer. I just took the convenient example on the GDK which uses significant amount of memory (~500 MB on my case after being warmed up) and reproducible (this repo is seeded and should be available for everyone in the dev env).

From our Mechanical Sympathy alerts, we noticed that on production, it sometimes takes 1.9G of mem usage: https://gitlab.slack.com/archives/CGN8BUCKC/p1617961708152100?thread_ts=1617960908.149400&cid=CGN8BUCKC

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Tested manually.

Security

N/A

Related to #326312 (closed)

Edited by Aleksei Lipniagov

Merge request reports