4 ms·
Just wanted to add that we're working hard to bring down the request time in GitLab 8.x. We're not there yet but already optimized a lot of SQL queries and this
by sytse 11y ago
Just wanted to add that we're working hard to bring down the request time in GitLab 8.x. We're not there yet but already optimized a lot of SQL queries and this release added support for better comment caching to prevent markdown parsing. Edit: we had to revert the comment caching at the last minute due to a bug but we're working on that, many other improvements and performance monitoring with InFluxDB and Grafana
- lhecker 11y agoI can definitely confirm that somewhere around the 8.0 release (I forgot when exactly) GitLab got a lot faster in general. Previously with the 7.x line it took about a couple seconds at least to load a page but now I barely get over a second until "onload", with response times of about 400ms. In general I wouldn't consider performance with GitLab an issue and denote it as a selling point for Gogs anymore - it would just be nice if it no longer felt like a Ruby on Rails website... A optimized site of mine with similiar complexity and database setup has a response time of 16ms and an "onload" event after about 400ms (using PHP-FPM 7 & MariaDB). ;)
- sytse 11y agoGlad to hear performance got better in 8.x. What can we improve to make it feel better?
- tiku 11y agoLess memory usage.. I went from gitlab to gogs because of that.. 2gb usage while idle..
- sytse 11y agoThanks, we're working towards a multithreaded application server to reduce memory usage https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592