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. 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...
--Brian
