On Wed, 20 Dec 2000, Nick May wrote:
> In particular, how does the server "know"? How exactly does it determine
> that it has a static page for that request, then locate that static page
> in the file system?
Well, how the server knows and how the cache is stored
is where the programmer comes in :) The example
flow in my previous mail was just intented to
simply describe how it works.
> If the site has a few thousand unique "pages" there becomes,
> potentially, quite a lot to keep track off...
It will only cache those pages which are requested. There
is no need to cache all the possible pages which the site
contain.
Things like search results might not be good candidates for
caching.
> cheaper than a complex sql hit) but a non-cached page would then create an
> additional hit. Or a flat file - that would get expensive real fast for a
> lot of pages
Reading a flat file is usually still cheaper than making
a complex query. There is additional overhead if the page
was not cached, but any additional queries for the same
page will be faster.
One thing you could do to to further reduce disk io
is to cache pages to filesystem in memory, not an
actual disc.
I believe with linux you could do something like:
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
with Solaris you can just use tmpfs which automatically
uses memory as long as it is available and after that
switches to discs.
> How did you do it, if you do not mind me asking :-)
Still doing it :) Will share what I learn in the process.
Caching dynamic pages in application level is nothing
new. I'm just doing my own implementation of it.
--
Mika Tuupola http://www.appelsiini.net/~tuupola/
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Wed Dec 20 16:23:17 2000