On Wed, Jun 04, 2003 at 11:42:18PM -0700, Steve Simitzis wrote:
> i'm still getting these, which i hoped would go away. :(

I don't remember saying it was fixed ;)

What we have is about 100 apache processes hitting Coda, which are being
handled by about 20 worker threads (maybe more if you've upped
maxworkers) which are hitting rpc2 with on most 9 connections per
userid, for which we have 8 'MultiRPC contexts'.

We can up the number of contexts in rpc2, but by how much? Upping it to
9 contexts would probably help your case.

On the other hand, the hoard daemon is running with it's own uid, and
there might be 1 or 2 user processes that access Coda (administrator and
updatedb/cronjobs). If we account for the worst case with this, we
already need 36 contexts.

But as you already noticed, 9 RPCs per userid is really not enough to
service all those apache processes that are getting about 100 hits/s
when the cache is still ramping up after a reinit. If we bump that to
20, we already need 80 MultiRPC contexts.

But we only have 20 worker threads and some other daemon threads
running. So we can never really have more than 20 + a couple concurrent
RPC requests at the same time.

What I'm trying to say is, all these arbitrary limits seem to be stupid.
These MultiRPC contexts seem like just another pool allocator that
doesn't scale. I'm tempted to just rip out and remove the 9 RPCs per
user limit. But this is not a change that I wanted to mix in with the
6.0.0 stuff at the last minute.

Jan