On August 10, 2002 05:32 am, Geoff Talvola wrote:
> On Fri, 2002-08-09 at 19:10, Tavis Rudd wrote:
> > That sounds right, but why tie the cache size to the number of thread=
> > If someone runs WebKit with large number of threads, say a hundred, i=
> > possible for this scheme to consume lots of memory during a flood.=20
> > Wouldn't be better to either a) maintain a count of the instances and=
> > into a wait loop if a request comes in while the cache is empty but
> > enough instances have been created, or b) put a cap on the size of th=
> > cache that is obeyed when returning instances to it?
> Why would you run WebKit with that many threads? Trying to process 100
> requests in parallel seems certain to lead to worse performance than
> limiting the number of threads to something reasonable (say, 10 or 20).
> And what's the point of _having_ 100 threads if only, say, 20 of them
> can actually be processing a servlet while the other 80 threads are
> blocking, waiting for a servlet instance? In that case, you'd be much
> better off only having 20 threads.
That's assuming that all threads are trying to access the same servlet, w=
is probably a fair assumption during a flood.
> So to me, if makes sense that the # of threads =3D=3D the maximum # of
> servlets in a servlet cache.
Ok, I agree. The code's also simpler this way, which is a good thing.