Last modified: 2013-06-10 14:46:35 UTC
The narrowest filter on GitBlit (14 days) pulls in too many commits: there are 1,473 commits listed on https://git.wikimedia.org/ presently, and they are represented in nearly two(!) glorious megabytes of HTML. This must be causing significant churn on the server, because it takes fully 8 seconds before it starts transmitting the response.
This can be set in gitblit.properties, apparently: # The number of days to show on the activity page. # Value must exceed 0 else default of 14 is used # # SINCE 0.8.0 web.activityDuration = 14 I propose changing it to 1. If the past two weeks were typical, then that would mean the default view would show about a hundred commits, and that the HTML payload would be roughly 140k. You can test the usability of that view by manually browsing to https://git.wikimedia.org/?db=1. We should also hide or completely disable other duration filters on the main page. The default set of filters (visible from the 'filters' menu at the top of the main page) includes a link to a 180-day view, which takes 30 megabytes and about 6 minutes to generate, and is marked no-cache.
See https://gerrit.wikimedia.org/r/67642.
I rolled back to gitblit 1.2.1 since the new landing page is unacceptably slow. Also merged the default activity filter to 1d.
