Closed tsuna closed 8 years ago
5 to 10 minutes for 70 repos just doesn't sound right. Something must be severely amiss in Gitblit. I wonder what it caches -- all commits?
I'll take a look and see what I can do, but it's an area of Gitblit that I haven't ever dealt with. Depending on what I find I may or may not be able to do something about it.
In any case: I have taken a (bad) habit of doing little fixes in Gitblit directly here in this plugin instead of upstream in Gitblit itself because Gibtblit for a long time was stuck at 1.6.2. It looks as if James now again releases more frequently. Gitblit 1.8.0 is out, and I'll soon switch to that. So I think you should report this bug against Gitblit itself.
Now that I've looked at that code, a couple of comments:
web.activityCacheDays
in gitblit.properties
to zero.See also gitblit/gitblit#1076 and gitblit/gitblit#1091. I'll put together a fix for the plug-in, and then see if I can push that upstream.
Fixed in the plugin in release v2.12.171.3.
If you could test, that'd be great.
When Gerrit starts, part of GitBlit's initialization includes preparing a 14 day commit cache. We repack our repos regularly, and don't even have that many (~70 repos totaling ~7GB of data) and yet it takes 5-10 minutes for GitBlit to build its commit cache, which significantly delays how quickly Gerrit can come back up after being restarted.
I don't know what the commit cache is used for, and I imagine the window (14 days) could be reduced via configuration (although I don't know what the consequences would be), but would it be possible to build this cache asynchronously in a background thread to not delay the startup sequence?