Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UCPdW-0006L2-4U for pgsql-www@arkaria.postgresql.org; Mon, 04 Mar 2013 07:16:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UCPdV-00078t-G3 for pgsql-www@arkaria.postgresql.org; Mon, 04 Mar 2013 07:16:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UCPdU-00078n-OQ for pgsql-www@postgresql.org; Mon, 04 Mar 2013 07:16:36 +0000 Received: from mail-wg0-f44.google.com ([74.125.82.44]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UCPdR-0003Ve-9J for pgsql-www@postgresql.org; Mon, 04 Mar 2013 07:16:35 +0000 Received: by mail-wg0-f44.google.com with SMTP id dr12so3879374wgb.35 for ; Sun, 03 Mar 2013 23:16:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=gQ97rPfKxNcHvMStFZkqNUMvv73W9BblB5Ix8z7qpag=; b=p5ge4FXc1D4kf7Xi1cuIiS3kB5tM7SZEoPPJZRhoOZhQ6QFMThrlPqNTZPpz3T6Tgn o6EMD7kb5UxIl9pNOftkM4k58u8NrqcTomjNbWV+wByS3jaZDpsAnidvo2msEev2t4QR b8hqj1Alqs8MKX6d/e/TT1eRY4Miey1Vym2LqgY2CFFG8WcLJ148DkK1V83vrzAunZr0 ZKHD1TjXAvl+nC3JsWxQdVrrmL1YJlS5gFzFAOALDzyhwraT/ngOsc7CBTaUGIGe4E+h MHwCgH3UDbHyz3VhoBmXdM2ao8Ms0GCPQkRGm4vPR+ywKmiwjS7mqoyHIPGWOS7dWc4r SjpQ== MIME-Version: 1.0 X-Received: by 10.180.103.65 with SMTP id fu1mr9519572wib.4.1362381392176; Sun, 03 Mar 2013 23:16:32 -0800 (PST) Received: by 10.194.171.40 with HTTP; Sun, 3 Mar 2013 23:16:32 -0800 (PST) In-Reply-To: <20130304023335.GH16142@tamriel.snowman.net> References: <19759.1362357835@sss.pgh.pa.us> <20130304020324.GE16142@tamriel.snowman.net> <2480.1362363162@sss.pgh.pa.us> <20130304023335.GH16142@tamriel.snowman.net> Date: Mon, 4 Mar 2013 08:16:32 +0100 Message-ID: Subject: Re: gitweb is no longer a real-time view From: Magnus Hagander To: Stephen Frost Cc: Tom Lane , PostgreSQL WWW Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmrWRsh6hY87iZZQ4U95U3K7odD83vNUo2FddDh43wSvLlzIposUmntkayNEZbM+WUquapg X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-www Precedence: bulk Sender: pgsql-www-owner@postgresql.org On Mon, Mar 4, 2013 at 3:33 AM, Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> cron job? I was under the impression there was some sort of push >> operation driven by a commit trigger. The web site has certainly >> updated nearly immediately for as long as we've been using git. >> Until this week, that is. > > Curiously, there's two cron jobs, apparently. There's a 'push' one and > then another, independent, 'pull' one. I'll assume they're actually > doing different things, but I wonder if the pull isn't just a > hold-over.. In any case, the push-to-anon, which I hadn't seen No, the pull one doesn't do the main repository - that one pulls "third party" repositories in as mirrors, such as e.g. Bucardo. That one was, btw, broken for several months and nobody noticed - so that's clearly a less important one :) > initially (looking at the pull side instead of the push side), does run > once a minute, though it looks like there's a hook mechanism which > would allow us to trigger the webserver to do a pull when a commit > happens and would still be better than a once-a-minute cronjob. The one that deals with the main repo mirroring runs once per minute. The commit trigger only drops a file in the filesystem so the cronjob knows there is something to do. So that we don't risk holding up the actual commit in case there is a problem with the anonymous mirror server. > Even with that, however, the concern raised was that the gitweb perl > script is quite expensive to run for every request, hence the reason for > doing the cacheing. I've lowered the varnish cacheing to a 5m ttl and > 15m grace and I'll keep an eye on it. That's fixing the wrong problem. The cache is supposed to be automatically purged whenever the push happens, to make sure that the data never gets more than maybe a second stale. So clearly something in that is not working - I didn't specifically test it with the postgres.git repository, but I tested it with a couple of other ones where it worked fine. But maybe we did something special with the main one... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-www mailing list (pgsql-www@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-www