On Fri, 2002-08-09 at 19:10, Tavis Rudd wrote: > On August 9, 2002 03:37 pm, Geoff Talvola wrote: > > On Fri, 2002-08-09 at 17:53, Tavis Rudd wrote: > > > Shouldn't _instanceCacheSize be used? It seems possible with the current > > > code for the number of instances to get out of control if there was a > > > flood of simultaneous requests. > > > It's impossible for an instance cache to grow larger than the maximum > > number of threads simply because of the logic of how requests are > > processed. Therefore there's no need to use self._instanceCacheSize > > (which I should have removed). > > 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. So to me, if makes sense that the # of threads == the maximum # of servlets in a servlet cache. - Geoff ------------------------------------------------------- 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
