On Mon, Nov 17, 2003 at 08:54:50PM +0100, André Malo wrote: > * Brian Akins <[EMAIL PROTECTED]> wrote: > > > Any thought into parsing the results of the includes filter (offsets, > > etc.). In our environment, parsing the includes files is a huge > > performance hit. > > Just some thoughts from top of my head: > > I'd say, if we do, only with the new code. The old one is not very applicable > for such a task. > > However, it sounds interesting. First we must define the cache keys. Cache by > URL? By file? by ETag? What about dynamic resources? > > The second point is, that caching in a performant manner probably only should > occur on per child basis (like rewrite map caching). This is highly useful in > multithreaded environments, of course. > > The third point is, that there's no real parse tree;-) We just skim through > the document and remember only the necessary things (FLAG_PRINTING etc.). We'd > need to remember what when happend, i.e. need to build a (kind of) parse tree > for exactly this purpose. (Array of "tokens" as a first thought). > > But there's still the question whether this really saves performance. This > depends on how fast the actual bucket stuff around is (compared to the parsing > code). We still must read the buckets and pass them through at minimum. > > Last but not least; it would be quite interesting to create just an abstract > API for this in mod_include and build another module that does the actual > caching. I'm not sure whether this make really sense, however ;) > > Further thoughts if I have more time ...
How about an env variable flag extension in the SSI that can be set to, say, "cache me". If you do any complicated processing, you would say "don't cache me", which would be the default. For files where server-side includes are used for page fragment reuse rather than complicated server-side conditional processing, this could be an easy win, and a bit more flexible than the XBitHack. Cheers, Glenn
