Jeff, Seeing Richard thinks I have blue (?blood) in (my) veins, I'd better respond nobly and quickly...
> 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 first) > 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. =dn -- 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]
