Hi, I tried setting up ArchZoom and it was pretty easy indeed (especially with the Debian Etch package) :)
http://arch.savannah.gnu.org/archzoom/ I activated the revlib, we'll see how it goes. Currently we have enough free space at Savannah to test it out. -- Sylvain On Wed, Nov 29, 2006 at 11:41:27PM +0100, Sylvain Beucler wrote: > Hi, > > I remember Michael installed ArchZoom at Savannah and, seeing the > comment at Gna, we decided not to load the (at that time) much-loaded > Savannah some more. > > Since then, we performed a bit of restructuration which improved the > load. Moreover, there aren't that many Arch archives right now > (compared to CVS), so this would worth a try. > > > Would you be interested in setting up ArchZoom at Savannah? Or for a > start, do you have some advice on what I should look at? :) > > > By the way, I also have a friend who disabled Arch at his website > (patapouf.org - vcs.patapouf.org) because ArchZoom would apparently > consume too much /tmp space for its own good. Does that ring a bell? > > Thanks, > > -- > Sylvain > > > On Wed, Oct 18, 2006 at 08:40:36PM +0000, Mikhael Goikhman wrote: > > [I was offline for a long time, so the late answer.] > > > > It does not seem the "bad performance of archzoom" issue is presented > > correctly. I can't say whether the Savannah administrator ever enabled > > archzoom. As for gna.org, the issue looks pretty simple. The > > administrator decided he has no many servers and wants to dedicate his > > single server to subversion browsers and not to arch. > > > > Here is some info that may help. The default archzoom configuration is > > conservative in that it does not try to write things to a user's disk. > > This is good for a demo installation, but requires tuning for production. > > The ArchZoom FAQ explains how to trivially define revision library that > > may cause tla to be drastically faster. It also explains how to keep the > > size of this revision library constant using "axp revlib prune --params". > > > > Another related problem is that many developers have unresponsively huge > > branches of thousands of revisions without a single cacherev, that makes > > certain tla operations totally stuck when working on these branches. A > > policy of automatic creation a cacherev every 50 revisions partially > > solves this problem. > > > > By default, archzoom forbids search engines to crawl its pages, but some > > web server misconfiguration or misbehaved robots may cause some unwanted > > bombing too. To solve this problem archzoom has a number of configuration > > options, for example it may limit the number of its instances. Problems > > like these described in the last 3 paragraphs are the real issue and it > > has nothing to do with archzoom. > > > > As a side note, certain tla operations (see threads about "tla abrowse", > > for example) are needlessly unoptimal, and may be improved noticeably. > > Many tla commands miss a limit, as others mentioned. > > > > I think the perl layer has a quite little overhead that is minor compared > > to the real problems related to tla and a web server. I don't really see > > "tla librification" essential, as long as tla behaves like a good library > > (and it is pretty close to it); fork+system is cheap on unix. > > > > As for the idea of making tla to behave more in a daemon manner, I am a > > bit skeptical about this, but I should see more info to form any opnion. > > ArchZoom implements some of this stuff, it has own mechanism of caching > > many of the views for several hours, so that tla is not called. I think > > it may also work under mod_perl if one wants this, however the standard > > CGI mode together with limiting the number of archzoom instances may work > > as well. > > > > Regards, > > Mikhael. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
