Re: Per EndPoint Threads???
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, 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
Re: Per EndPoint Threads???
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 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, 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 > >
Re: Per EndPoint Threads???
-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 > 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, 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
Re: Per EndPoint Threads???
On Sat, Aug 12, 2017 at 9:36 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -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 > > 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, > 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 > > Well caching is: - related to resource not
Re: Per EndPoint Threads???
On Sat, Aug 12, 2017 at 9:36 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -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 > > 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, > 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 > > I think I understand the confusion. The ol
Re: Per EndPoint Threads???
-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 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, >>> 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 pF
Re: Per EndPoint Threads???
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 > 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, > >>> 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 co
