> Greg Ames wrote:
>
> >"Victor J. Orlikowski" wrote:
> >
> [...]
>
> >If ssi's were working, and you were measuring them, I think we would see
> >2.0 look a lot worse compared to 1.3, and threaded worst of all, because
> >we don't have a fast mutex-free replacement for malloc/free yet <sigh>.
> >For the buckets code, having some kind of connection lifetime apr_pool
> >might be good enough, if we had a way to terminate keepalive connections
> >that ate too much memory. But we need a good apr_malloc/free for other
> >stuff anyway, like caching.
> >
> 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.
I've replaced the malloc/frees in the bucket code on Windows with a power of 2
allocator
and it makes a BIG difference in performance. I expect the same on every OS with the
exception of Linux.
> 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...
Certainly.
>
> --Brian
>
>
>
