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.
Thanks again for your answer. Owen Rubel oru...@gmail.com 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. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
