> >>>Even with straight HTML, a server's load capacity is not infinite.  If
> >>>my own server, an old Pentium with 4 GB of hard drive space, and which
> >>>serves nothing but static HTML pages, got hit with more than a couple
> >>>hundred hits in a short period of time, it would bomb.
> >>>
> >>>I must be misunderstanding your question.  I've re-read your original
> >>>post, and it seems to me that what you're trying to do is save
> >>>webpage-bound database data in a way which will seriously reduce the
> >>>load on a webserver; creating static HTML pages from database data
> >>>instead of building pages dynamically when the user calls them would
> >>>accomplish that goal, and that is what I was suggesting.
> >>>
> >>You are right ;)
> >
> > er, yes and no!
> >
> > Jeff's original post mentioned reducing load on the db server - are the db and web 
>servers on the same
> > device - and thus his concern?
> > - or perhaps if there are other apps needing to 'compete' with the web server to 
>gain access to the db
> > concurrently?
> In which case, it seems to me that my solution would still be a good
> one.  Reducing the number of hits on the database server by building
> static pages as needed to be served up by a web server would still
> reduce the load on the database server.

I thought we were basically agreeing - should I be arguing with you?

Depending upon how far Jeff wants/needs to go, he can either reduce/remove database 
traffic (only) by 'locking
in' the retrieved data (articles) - either as they are written/approved/whatever or on 
the first occasion a
web-request is received;
he can do that and go to the next step - generate static HTML pages and thus remove 
the necessity to run browser
requests through PHP as well, ie reduce his web service load to Apache only.

Personally I would presume the second to be 'best', but I don't know all the facts. 
For example, we can't say
that dynamic db load will be driven to 'zero' because there might still be a need for 
user authentication...

Good idea!

PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to