Re: [Bug-gne]A suggestion for reformulation

[Hook]

Tom Chance wrote:
> > > As for processing power, unless we use a single
> > PII
> > > 450 to do the serving, I'm not sure processing
> > power
> > > is going to be much of a problem. Especially if we
> > use
> > > Perl, because then we can use a small bank of
> > > interpreters to do the number crunching, and a
> > main
> > > computer to act as the "gateway", to hold the info
> > > etc. We shouldn't offload our problems onto the
> > users,
> > > we should solve them all ourselves.
> >
> > With database servers the main issue is memory
> > rather than raw CPU power.
> > MySQL responds well to proper tuning, most of which
> > relates to telling it
> > how to use the memory it has available.
>
> Which, IMO, still points to us doing most of the work.
> In terms of the database server, it could well be a
> seperate box to the HTML server if we wanted it to be.
> And lets think how many simultaneous accesses we're
> likely to get. Submissions, certainly for at least a
> year, probably won't outstrip 3 a day. I doubt we'd be
> likely to have more than 20 simultaneous etrievals for
> viewing articles from the database, and if we get a
> machine with a decent CPU and 512mb of RAM, I doubt
> we'll ever hit any problems. And as the resource
> grows, the increase in demand will spread across more
> mirrors, and we can upgrade our main mirrors
> ourselves.

Oddly enough, separating the requester from the database server makes little
difference to the database performance. One of my work environments is a
database server with 256 Mb of RAM and it copes with 100 simultaneous
connections. The issue is the amount of RAM available for handling indexes,
and I doubt that GNE will have an overly complex schema.

However, 512 Mb is sensible and the functional split between requests and
database allows the requester to know about multiple database servers (if
necessary - that's a very clumsy way to get load balancing and ought to be
avoided though), and allows multiple requesters perhaps handling different
"views" of the content.

Paul