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 threads. > > If someone runs WebKit with large number of threads, say a hundred, it's > > possible for this scheme to consume lots of memory during a flood. > > Wouldn't be better to either a) maintain a count of the instances and go > > 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 the > > 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, which is probably a fair assumption during a flood. > So to me, if makes sense that the # of threads == the maximum # of > servlets in a servlet cache. Ok, I agree. The code's also simpler this way, which is a good thing. Tavis ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
