Re: Package search improvements
On Wed, Apr 23, 2003 at 01:50:26AM +0200, Frank Lichtenheld wrote:
> It's disk space against cpu usage. Clearly the first is much cheaper.
Perhaps I should also mention the exact cause of those 500 errors that was
briefly mentioned on -www recently -- the MaxClients 300 setting on gluck
exceeds the maxproc 256 setting. Of course, this is a bug, and it will be
fixed, but this still means that apache on the machine often runs two
hundred processes as it is, so adding more CGIs/PHPs wouldn't exactly be the
happiest solution.
Some might mention, why don't we put it on another machine -- we do that
kind of stuff already, but even so, we shouldn't waste stuff on principle,
and fact is that most of the scripts are lightweight (download.pl,
subscribe.pl or redirect.pl), and those that aren't, suck :) (searchlists).
Making packages.d.o backend first parse all Packages files from all
architectures, sort -u the list, and then go through the data ordering it
per package, would seem to do the trick. Of course it would also track
Architecture fields and pass them as parameters to download.pl.
(Heck, even download.pl could be eliminated, it's not like anyone changes
the selected mirrors often (they're selected for the very purpose of being
reliable and not necessary to change).)
> The only question I have: When I want to help on this, in which
> direction should I go so that when I invested some time in it I will
> not just hear: "Nice what you've done, but completly useless for us"
I'm sure my constant bitch^Wsteering in the right direction will prevent
that ;)
--
2. That which causes joy or happiness.
Reply to: