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 [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
