On Sat, Aug 12, 2017 at 3:13 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Owen, > > On 8/12/17 12:47 PM, Owen Rubel wrote: > > On Sat, Aug 12, 2017 at 9:36 AM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > 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 > >> > >> --------------------------------------------------------------------- > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > Well caching is: - related to resource not communication - is a one > > time thing and has to have a version check every time. > > > > What I am talking about is something that improves communication as > > we notice that communication channel needing more resources. Not > > caching what is communicated... improving the CHANNEL for > > communicating the resource (whatever it may be). > > > > But like you said, this is not something that is doable so I'll > > look elsewhere. Thanks again. :) > > If you want to improve communication efficiency, I think that HTTP > isn't the protocol for you. Perhaps Websocket? > > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmPfYEACgkQHPApP6U8 > pFivQg//RACaNIne3hC5nlpoQATZ1qDl6zJLrGD9qSyooRkAeQxmOS2AlIZgrdzP > c69Ze3hIRSaxGW0ecdm0weRINimtKqjJqGsEa6AOWsWyC6KUMk6L63cLIvmoNl7t > 7kUK/YeOfD4dVnHBcy4QeOY0svVHP9CLPT7wnNv4qH02+ZzB3CtEXu5gOFmUg7Zk > H7R8tKKce0RtNWtf2UDrlYy2ZKrpTsp5G4KI8p3hmKeIxY1UyItNbxRTL53OMDSU > 9negiFcHGxf8JKQPq+Uqh08Bj+ZGlY4tdlhmY+MWNEJnu4DQPlx67QfHGlbmz1Cc > Eegnb2Rc5DEBvnaj8Ow7vgjTAosng3BQ2dLJR9m+nfzBpGfsAFbMPDp5LEsPQH3P > Erw/OY9gUt41jqqOq0K5uiB//tu0KMfeR4XPGZ0avq12lv2zYfbp6oDIidFsAPpd > TiZOV1GsJhLVe61nG28+QTDxBuzWuaoBqPmVmNb+vT3DC37VbRG1v/9dnX3mn373 > dB87iKnb8VGTbAP2loTV0OsyBtpn8ruc3WNURHgAgxKADmettG6c47WxDN2HwPpH > L6avgIkiGhS/3y7quDNo8JD08VQpuMtxiVsdt5xwsC6fdHtkNgbSG/2qCAgKQcKQ > DNiadO15ASuTm59e3Tqmk6vVhtMvsc+cWeq6T5x5tXyXPSP2VpA= > =sDX7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Well I'll try not to take offense at that...heh. You may not be aware of my contributions to date. :) But again, appreciate the feedback. So thank you.