httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason S. Clary" <>
Subject Re: idea - last-modified despite SSI - possible performance booster
Date Mon, 03 Feb 1997 06:56:14 GMT
> Sure.  I guess "object cache" was imprecise - what I'd cache initially is just
> the offsets of the SSI directives in the file, so that parsing can be avoided.
> This is not a solution to "how to apply last-modifieds to SSI files" but
> instead "how to speed up SSI serving".  The cache could be an mmap()'d stretch
> of memory shared between processes, which gets cleared whenever a signal is
> received.  

I still think some sort of pre-processing would be incredibly usefull..
you could even mark the locations of SSI directives that require updates
on every hit during the compile stage.. On a site that uses a lot
of SSI for easy maintenence (which is one of the beauties of SSI,
simplifying the code from a webmaster's standpoint) it could speed
things up incredibly..

if all SSI's were sortof pre-compiled the first time they are hit after
the source changes, and a short list of dependencies were created
and a short list of offsets and stored in a file then if the pages
only change once every week or two it would increase ifficiency
a thousand fold...

Bit complex though..  And someone would have to come up with an
"object" format of some sort that had a header with say first byte(s)
being the length of the header than contains the dependencies and
offset info...  then everything after that being the code itself..
You might even be able to convert the actual SSI commands into
a more easily parsable format and remove them from the document all
together in the object version.

The hardest part being, of course, locking and lock collision handling
during a recompile.  You'd probably want to create the new object
in the /tmp dir and not overwrite until its done..  that one hit
would be delayed by a millisecond or two but all other his would
process almost instantly and with a minimum of memory overhead.

Also, you don't have to deal with the trouble of shared memory mapping
and whatnot, plus the other ideas about NFS caching and proxy caching
would still be just as effective on top of it...

Course, I don't know if any of you are into compiler style approaches..
but it would also, if designed right, lend itself to precompiled embedded
coding like perl and lite script and the others which could all
benefit greatly  (lite actualy has a precompiler, similar to java).

Its a lot of trouble to go through for a small hobby site, but it could
mean the difference between a heavy SSI site serving a hundred or
two thousand hits a day to serving over a million on the same
amount of memory.

View raw message