On Wed, Nov 27, 2002 at 09:39:52PM +0100, Benjamin Pflugmann wrote: > 5. Another hybrid: Do not create the cache pages yourself. Simply > build the back-end as in solution 1. and put a caching proxy > (e.g. squid) before it. The main drawback in comparison with. > Depending on proxy, may scale bad on restart. Depending on > configuration and usage may even be faster than 2. Is as out of > date as you configure it to be: the more current the pages shall > be, the worse it scales (because it less often hits the > cache). Medium work, scales good, actuality: as configured. > > 6. As 1., but allow client-side caching of pages. This only has > positive effects on reloads or often visited pages. Least work, > scales bad, actuality: as configured (same as 5.)
As someone who uses 5 & 6 together quite often (as suggested), I can tell you it works very well (and very responsively). Your point about oft-used pages is interesting, but it only applies in a special circumstance that, in my experience, doesn't happen often (although Slashdot does consider this): If a page would require significant database resources and the source information changes more rarely than the data is accessed and/or the data may be accessed when it is inconvenient to load the database server with such a query, generating the page offline and storing it makes sense (like the Slashdot archived stories). In most cases, however, doing no caching at all is sufficient and allowing client-side caching takes the load off the frequently used pages (which is all you really care about usually) and adding Squid or Apache doing caching in front of your live server takes away hits to the same data from multiple requestors. > Since 1. allows to continue with 6., 5. and 4., I suggest to start > with solution 1. and then continue as much as need arises. I agree with this, personally. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
