Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Web caching



My curiousity is piqued: can one use a RAMdisk to run a dedicated Apache
cache assuming the memory is available or is it just best to use the fastest
disk possible, perhaps a mirrored RAID set?

"Mark J. Dulcey" wrote:

> Ron Peterson wrote:
> >
> > I'm curious.  Does Apache cache static web content in memory?  I.E. - if
> > I request a static page, does Apache store that page in memory for some
> > period of time, in case someone else asks for it?  Or does Apache fetch
> > the page from disk each and every time?  If it is cached, then for how
> > long?  Is there a cache timeout parameter?
>
> I believe that Apache simply fetches the file from disk each time. Of
> course, the underlying operating system is likely to cache the file.
> It's not clear that adding a cache to Apache would be better than
> letting the OS handle it; the likely result would be to have Apache
> cache too little (slowing it down) or too much (slowing other
> applications down).
>
> > Taking this a step further, would PHP perhaps do the same thing?
> > Obviously dynamic content, like database data, would need to be
> > requeried, but the php files themselves could be loaded every "x" number
> > of minutes or something.
>
> I know that mod_perl caches loaded code, so that it doesn't have to
> reload and recompile it. That's a much more expensive operation than
> simply fetching a file from disk, so an internal cache is the right
> thing here. I don't know what PHP does.
>
> This, of course, can be awkward in a development environment - your code
> changes don't take effect right away. I suppose the solution is not to
> run your in-development scripts under mod_perl unless you have to (if
> they're depending on looking at some Apache internals, for example).
> -
> Subcription/unsubscription/info requests: send e-mail with
> "subscribe", "unsubscribe", or "info" on the first line of the
> message body to discuss-request at blu.org (Subject line is ignored).

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org