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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
