Brian Pane wrote:
> I know the conventional wisdom is that SSI is slow because of
> the malloc calls in bucket creation, but the problem might
> be elsewhere. I've tried adding in a free list of recycled
> buckets, to reduce the calls to malloc, but it didn't seem to
> affect performance measurably.
hmmm, interesting. Just a while ago I was testing SSI's on daedalus
because of the mod_include problem with
http://httpd.apache.org/docs-2.0/misc/FAQ.html . The functional bug is
gone, but it was abysmally slow (2 req/sec). top said we weren't
burning up the CPU (94+% idle). server-status had every worker in "W"
state. ps ax -O wchan said almost everybody was blocked in select, so I
wrote it off as a bandwidth constraint on the path back to my ThinkPad.
> The bottleneck might instead
> be centered on the other operations required for brigade
> in SSI requests in 2.0, like splitting buckets and registering
> pool cleanup functions. Further profiling should be helpful
> here...
It would be great if we could get a handle on this somehow.
Greg
