Source: gitlab
Version: 12.9.2-4
Severity: normal
Current assets building through webpack is done by the following call
set in /usr/lib/gitlab/scripts/rake-tasks.sh:
runuser -u ${gitlab_user} -- sh -c 'NODE_OPTIONS="--max-old-space-size=2048"
webpack --max-old-space-size=16384 --config config/webpack.config.js'
The issue with this command is that it does not build assets optimized
for use in production, making parts of the GitLab interface heavy on
bandwidth usage, and slow to use on networks with limited bandwidth.
The suggested replacement should fix this issue by explicitely building
assets optimized for production use:
runuser -u ${gitlab_user} -- sh -c 'NODE_ENV="production"
NODE_OPTIONS="--max-old-space-size=4096" webpack --config
config/webpack.config.js'
The modifications are:
- Add NODE_ENV="production", this is what triggers the correct assets
build mode
- Replace NODE_OPTIONS="--max-old-space-size=2048" by
NODE_OPTIONS="--max-old-space-size=4096", as it seems build in
production mode uses more memory (an alternative would be to make the
value configurable in /etc/gitlab/gitlab-debian.conf)
- Drop --max-old-space-size=16384 as it has no effect here, and probably
was added by mistake while fixing #956211
Thanks to these tweaks, served assets are much smaller and the overall
UI is much more responsive. As an example it takes main.chunk.js from
~25 MB to less than 3MB, before application of gzip compression by
nginx.
For a comparison, both of these GitLab instances use the same GitLab
version based on buster-fasttrack repositories:
- https://gitlab.debian.net/explore - not using the production assets
- https://forge.dotslashplay.it/explore - using the production assets
The difference in responsiveness is easily noticeable, and the
difference is bandwidth usage is important.
