gogs: Slow repository browsing response times

Configuring Gogs, browsing the commit log, searching, pushing/pulling, etc. is all fairly snappy, but browsing the files of a repository is (comparatively) very, very slow.

For example, I have a repository with 30 entries in the root, and 147 folders in a nested folder. The total page time (as seen at the bottom of the page) is ~700ms for the root, and ~4000ms for the larger nested folder. I realize that’s still only 23-27ms per item, but the sum total lag is significant, and makes it difficult to browse between folders. The template rendering time itself is negligible (~10ms).

Below are the top results of an strace -cfp pidof gogs`` for a refresh of the 147-item folder. Note this only shows the time spent in syscalls, which is only about a quarter of the total time (it takes twice as long when strace is running):

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 30.50    0.749541         603      1242           futex
 17.68    0.434417      217209         2         1 restart_syscall
 17.55    0.431308         936       461           epoll_wait
 14.96    0.367632        1585       232           wait4
 13.43    0.329996        2750       120           sched_yield
  2.48    0.061040          90       676           select
  1.07    0.026240           5      5618           read
  0.46    0.011213           2      5789           mmap

Gogs version: Gogs version 0.6.3.0802 Beta Git version: git version 2.5.0 System: Fresh install of CentOS 7 in a single-core VM on a Windows 8 host (Hyper-V). No anti-virus.

Any idea of what might be causing this?

About this issue

Original URL
State: open
Created 9 years ago
Reactions: 1
Comments: 39 (10 by maintainers)

Commits related to this issue

fix go get sub package and add domain on installation to let go get work defaultly (#1518) * fix go get sub package and add domain on installation to let go get work defaultly * fix import sequenc... — committed to unfoldingWord/dcs by lunny 7 years ago

Most upvoted comments

I don’t know for gitlab but i thinks that github take the approach of displaying the file list directly and retreiving after the hash from api. This will also permit to divide the problem and focus on optimizing (maybe by caching) the hash retreiving separatly.

sapk on Apr 8, 2016

Do we have any progress on this?

agherzan on Feb 22, 2018

I have made a mirror of github.com/torvalds/linux and pageloads are between 6 and 40 seconds for this repository on my machine. This process runs with 100% CPU while the page is loading: git rev-list --count <SOME_HASH>. Maybe we can cache the the output of git rev-list --count ...?

klingtnet on Sep 1, 2016

I might use https://github.com/src-d/go-git to test see if we can have any performance gain.

unknwon on Mar 14, 2016

Thanks your detailed feedback!

Any idea of what might be causing this?

In my opinion, I think it’s not a topic about what causes this, instead, it is because Gogs hasn’t had a cache system for repository Git data(it reloads everything every time you visit a page).

The speed should be improved at some point in the future release.

Hope my explanation help you understand. 😄

unknwon on Aug 20, 2015