Skip site navigation (1) Skip section navigation (2)

Web mirrors

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: <pgsql-www(at)postgresql(dot)org>
Subject: Web mirrors
Date: 2004-12-23 16:13:01
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4528129@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgsql-www
Hi,

Devrim noticed a problem earlier today with our web mirrors. The new
site requires the Apache mod_rewrite module to be active on the server,
and for the server to be configured to honour a .htaccess setting
enabling MultiViews). If this is not configured, then some pages will
give 404's on the mirrors.

In considering  how to handle this though, I looked at the stats
recorded by the new clickthru counter used on the mirror pages. Since we
went live yesterday, only 141 web mirror selections have been recorded.
By contrast, there have been 6660 (!?!) clickthrus to ftp mirrors and
torrent files. We currently have 58 active web mirrors, each rsyncing
around 10,000 files at least daily which seems to me like a huge waste
of cpu cycles and disk accesses (bandwidth should be minimal as rsync is
quite efficient on the network).

So, the question is, should we get rid of the bulk of the web mirrors,
and leave say 5 in place around the world, which are all configured in a
round-robin DNS arrangement with www.postgresql.org? These mirrors would
be fast, reliable ones, hosted by people we know and trust, who are able
and willing to configure the virtual host to our requirements (something
we might not be able to get all the existing mirrors to do - especially
if they are not running Apache, or don't have mod_rewrite compiled in).

What do people think?

Regards, Dave

PS. I do not propose to change anything on the ftp mirror side - they
are definitely worthwhile.

Responses

pgsql-www by date

Next:From: Dave PageDate: 2004-12-23 16:14:28
Subject: Re: Webpage
Previous:From: Bruce MomjianDate: 2004-12-23 15:45:25
Subject: Re: Missing archive entry

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group