Re: [RESEND] Pagination for gitweb

From: J.H. <warthog19@eaglescrag.net>
Date: Sep 10, 2010, 19:05 UTC
Message-ID: <4C8A816E.4090305@eaglescrag.net>
In-Reply-To: <m34odxmnpj.fsf@localhost.localdomain>

On 09/10/2010 11:57 AM, Jakub Narebski wrote:

Show 12 quoted lines

> Lubomir Rintel <lkundrak@v3.sk> writes:
> 
>> I thought something like this could be a starter for better handling long
>> gitweb project lists (such as http://pkgs.fedoraproject.org/gitweb/).
>>
>> Could anyone please take a look?
> 
> What do you mean here by "better handling"?  
> 
> Is the problem server performance for large number of projects?  If
> this is the problem, perhaps better solution would be to use caching
> (work in progress).

They already moved to using my caching layer, mainly because I could create an RPM for them and the fact that my caching code is slightly more battle tested.

Show 12 quoted lines

> Is the problem large projects-list page and bandwidth?  There was a
> patch adding transparent compression of pages generated by gitweb
> would be a better solution; perhaps this together with caching (to
> avoid performance hit on CPU; note that usually gitweb performance is
> I/O and not CPU-bound).
> 
> Is the problem client rendering performance on large page with large
> table?  If it is, then paginating output, or adding project search
> like in gitweb fork used on http://repo.or.cz is correct solution.
> 
> 
> So which is it?

I think the issue is just having something like 10K projects all suddenly staring you in the face on a single page, it's not so much a technical problem with gitweb itself as a mental problem of dealing with a giant webpage like that.

So far the Fedora guys seem happy with the way things are (well except for the fact that their front page takes something like 2 hours to build, which has it's own set of problems).

Just some additional food for thought.

- John 'Warthog9' Hawley