[Savannah-hackers-public] Re: [Gnu-arch-users] archzoom

[Sylvain Beucler]

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.