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 (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]