-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Owen,
On 8/12/17 11:21 AM, Owen Rubel wrote: > On Sat, Aug 12, 2017 at 1:19 AM, Mark Thomas <ma...@apache.org> > wrote: > >> On 12/08/17 06:00, Christopher Schultz wrote: >>> Owen, >>> >>> Please do not top-post. I have re-ordered your post to be >>> bottom-post. >>> >>> On 8/11/17 10:12 PM, Owen Rubel wrote: >>>> On Fri, Aug 11, 2017 at 5:58 PM, <christop...@baus.net> >>>> wrote: >>> >>>>>> Hi All, >>>>>> >>>>>> I'm looking for a way (or a tool) in Tomcat to associate >>>>>> threads with endpoints. >>>>> >>>>> It isn't clear to me why this would be necessary. Threads >>>>> should be allocated on demand to individual requests. If >>>>> one route sees more traffic, then it should automatically >>>>> be allocated more threads. This could starve some requests >>>>> if the maximum number of threads had been allocated to a >>>>> lessor used route, while available threads went unused for >>>>> more commonly used route. >>> >>>> Absolutely but it could ramp up more threads as needed. >>> >>>> I base the logic on neuron and neuralTransmitters. When >>>> neurons talk to each other, they send back neural >>>> transmitters to enforce that pathway. >>> >>>> If we could do the same through threads by adding additional >>>> threads for endpoints that receive more traffic vs those >>>> which do not, it would enforce better and faster >>>> communication on those paths.> The current way Tomcat does it >>>> is not dynamic and it just applies to ALL pathways equally >>>> which is not efficient. >>> How would this improve efficiency at all? >>> >>> There is nothing inherently "showy" or "edity" about a >>> particular thread; each request-processing thread is >>> indistinguishable from any other. I don't believe there is a >>> way to improve the situation even if "per-endpoint" (whatever >>> that would mean) threads were a possibility. >>> >>> What would you attach to a thread that would make it any better >>> at editing records? Or deleting them? >> >> And I'll add that the whole original proposal ignores a number of >> rather fundamental points about how Servlet containers (and web >> servers in general) work. To name a few: >> >> - Until the request has been parsed (which requires a thread) >> Tomcat doesn't know which Servlet (endpoint) the request is >> destined for. Switching processing to a different thread at that >> point would add significant overhead for no benefit. >> >> - Even after parsing, the actual Servlet that processes the >> request (if any) can change during processing (e.g. a Filter that >> conditionally forwards to a different Servlet, authentication, >> etc.) >> >> There is nothing about a endpoint specific thread that would >> allow it to process a request more efficiently than a general >> thread. >> >> Any per-endpoint thread-pool solution will require the >> additional overhead to switch processing from the general parsing >> thread to the endpoint specific thread. This additional cost >> comes with zero benefits hence it will always be less efficient. >> >> In short, there is no way pre-allocating threads to particular >> endpoints can improve performance compared to just adding the >> same number of additional threads to the general thread pool. > Ah ok thank you for very concise answer. am chasing a pipe dream I > guess. Maybe there is another way to get this kind of benefit. The answer is caching, and that can be done at many levels, but the thread-level makes the least sense due to the reasons Mark outlined abov e. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmPLngACgkQHPApP6U8 pFisbw//aiIg0vGmmlm4T/xoEbAKblKf6Qn9zmDzbLY9IbIG7MdsMcuV9hnsasEp iaZs3ROTy3BvWKGoyIGThtRsBPSFmb1H/XuKs4bqxgdRNgcbxEbjkH+1wZCx76Aq aqdIiCFdWvkOll4EqC4UYjNXCMkMBoTGN4GTxGmB8arujOyiC1KVPLY+wiRtXusF BrV3n9G+wN7Qq+rHIvgct1J29xTnPwQWhcdTrR5+IXn7vuNhEe9yxlKyJh4N6Pkt TW8ZlZfUgPnAXYZFvb0UfRK43cOCP4HsgncvIDjnnRJVTnaqRKBuRE4ZVYJG91SN CHUCYAmCR/rUZcOO3VJZ0dE7OEkrtcs6tmRT7j0qfS2qxbAb6YuW5xNYrCTgWKyD 6bUCQsKzcChV4mQPVDjXO/yv1t3dpXeMB+44KwCVB3bFPTediwISzTxInCSd/Kdu I+57Rcrclto8S3+GRsUPRG3dwsNMYMIxHpuzj/LYzLNdoANI8vM5NntYdQ4cwEFM H23i54m00WQ5RLuRJGzker+T5H0NvGlVwFQnqO9kCkA57o1Gi+vk34UuNPVLsqHx sKq6Eb4s3MeslZBPHhJWYXGPx226+T6sEXO1y2UZ9GuWYzfI3MF6/xcFOI2/W3id kYZEnR3R1Xes7GzsSLuCXVRDQco3GhXvSiyLvYC9xwgIsjnM61Q= =Q/vf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
