httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Fear <>
Subject Re: [BUG]: "Argument passing in <!--#exec cmd=...-->" on Linux (fwd)
Date Sun, 09 Feb 1997 06:54:57 GMT

I wrote:
> This may be xssi related.  But, I'm on vacation in an airport in San
> Francisco and won't return until Saturday.

Rob Hartill writes:
> Strange place for a holiday.

Well, my wife and daughter were staying with my in-laws.  Need I say

I'm back from vacating.  I've sent comments on the two problems I'm
aware of and will follow-up with patches in the morning.  As far as
I can tell, the rest of the ssi issues are on performance:

    1) The ssi code itself is pretty straight without a lot of
       performance tweaks.  It really wasn't designed to be the
       default processing mode for busy servers.

    2) The code is pretty ugly which was in large part my doing.
       Certainly the directive and expression processing parts should
       be done by tables instead of large case and if statements.

    3) I don't really understand why mod_include would be so much
       slower for 1.2.  It really doesn't do all that much except act
       as a simple filter.  And that logic hasn't really changed that
       much.  If there is a performance problem, I would
       look at the changes on either end of the filter: opening and
       reading the file and writing to the socket.

       As mentioned in other posts, buffering the input should be
       done by the system for me.  Although mmap would be better
       where available because that's its job in life.

       On the output side, rputc (and bputc) should be buffering
       anyway.  And that didn't change either.  Both are actually
       pretty straightforward.  I believe that the patches submitted
       just created another (local) level of buffering which will
       be done much more cleanly by 2.0's I/O streams.

    4) I wouldn't think there would be much gain from speeding up the
       search for '<!--#' over a couple of thousand bytes. 
       Particularly since, as a filter, it has to process each of
       those bytes anyway.  Although, as the default mode for busy
       sites, every bit helps.

Of course, those are the comments of a programmer thinking about
performance which is about the worst source there is.

Howard Fear      I'm just a country perl hacker Jim.

View raw message