-----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
