From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J.H." Subject: Re: [RESEND] Pagination for gitweb Date: Fri, 10 Sep 2010 12:05:18 -0700 Message-ID: <4C8A816E.4090305@eaglescrag.net> References: <1284135442-10971-1-git-send-email-lkundrak@v3.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lubomir Rintel , git@vger.kernel.org To: Jakub Narebski X-From: git-owner@vger.kernel.org Fri Sep 10 21:31:52 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou9KB-0003oK-Pc for gcvg-git-2@lo.gmane.org; Fri, 10 Sep 2010 21:31:52 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753448Ab0IJTbq (ORCPT ); Fri, 10 Sep 2010 15:31:46 -0400 Received: from shards.monkeyblade.net ([198.137.202.13]:46072 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752737Ab0IJTbp (ORCPT ); Fri, 10 Sep 2010 15:31:45 -0400 X-Greylist: delayed 1571 seconds by postgrey-1.27 at vger.kernel.org; Fri, 10 Sep 2010 15:31:45 EDT Received: from voot-cruiser.eaglescrag.net (c-71-202-185-40.hsd1.ca.comcast.net [71.202.185.40]) (authenticated bits=0) by shards.monkeyblade.net (8.14.4/8.14.3) with ESMTP id o8AJ5IV8012240 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 Sep 2010 12:05:18 -0700 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at shards.monkeyblade.net User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.6 In-Reply-To: X-Enigmail-Version: 1.0.1 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (shards.monkeyblade.net [198.137.202.13]); Fri, 10 Sep 2010 12:05:19 -0700 (PDT) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On 09/10/2010 11:57 AM, Jakub Narebski wrote: > Lubomir Rintel 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. > 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