Seeing Richard thinks I have blue (?blood) in (my) veins, I'd better respond nobly and 

> Yes the db server and the webserver are on the same box, local
> connections are much faster than network ones according to mysql.  When
> the site is busy the percent of the system being used by mysql and that
> being used by PHP/Apache, I estemate would be around 90%-10% so if I get
> the db load down I'll have smooth sailing.

=sounds like a plan - unless you simply up the h/w and/or performance... (but you'll 
have thought of that one

> I'm not attempting to elimate the compalition of PHP, I just want to
> eliminate some database queries.  I don't particually care for the idea
> if writing static html files. I've had really bad experiences with stale
> files our old system.

=I'm intrigued. Surely rendering the pages as db-less='static' PHP is going to be just 
as much work as preparing
them as HTML (with the attendant performance improvement).

=Before we got into three-level systems, static stale pages were a real problem as 
soon as volumes got 'up
there'. However you will be generating the static pages (whether in HTML or PHP) from 
a database back-end. Thus
it would be simple to catalog each 'view' (can I call them that seeing MySQL doesn't 
offer db views at the
moment) in the self-same db, together with an expiry date-time. As new 'views' are 
being generated the db
back-end can also order the termination of expired/stale views - you yourself talk 
about TTL below, all I'm
doing is suggesting moving it 'forward' to view-creation time!

> The way I'm exploring now is to build a caching layer between the php
> application and mysql.
> I want the app to query the caching layer just about the same way it
> queries the database, but add a few other details, time to live, cache
> name etc.  The caching layer will check to see if the query is cached,
> make sure it's not expired, and return the data just like a result set
> from the db query.  If it is expired, or doesn't exist then it will
> query and create the cache file for next time.
> I'm leaning toward storing the data in XML, and kicking around the idea
> of storing it on a ram disk so it would have killer fast access time.

=isn't one of the criteria of using RAM disks, space requirement minimisation (he says 
getting the theme firmly
between his teeth...)

=yes it would require less storage to hold the data, than to hold the entire HTML page 
- but what do the
percentage figures really look like.

=It sounds like a good idea to me - although XML is not exactly storage-friendly.

> I expected to get tons of links to libraries or other apps that have
> data caching, I'm quite supprised that I haven't yet.

=sorry, I wish I could remember where I saw that article.

PHP General Mailing List (
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