Dear Christopher, Really appreciate ur quick response! Sorry for late reply due to personal affairs...
>>>I haven't read the code in detail, but I'm guessing that the thread pool uses a queue and not a stack of threads, so each thread gets used, repeatedly, in order of availability. >>>Note that Tomcat's thread pool is just a wrapper around >>>Java'sThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle events, etc. >>>So if the pool isn't behaving as you'd like it, you'll need to file a but against the Java API and not Tomcat. [Roy] Based on ur comment, my understanding is tomcat is using Java'sThreadPoolExecutor, Java's ThreadPoolExecutor pick up new threads from thread pool using FIFO approach. Regarding "So if the pool isn't behaving as you'd like it, you'll need to file a but against the Java API and not Tomcat.", do we have any mature solution (e.g, any open source project) which change the tomcat thread pool's behavior (e.g, FIFO approach)? Thanks in advance! Thanks, Roy On Fri, Nov 1, 2019 at 9:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Roy, > > On 11/1/19 08:23, Roy Zhang wrote: > > I am confused about "keep alive time" value in Embed Tomcat. I am > > using Spring Boot 1.5, embed tomcat version is 8.5. > > > > According to > > https://github.com/spring-projects/spring-boot/issues/16450#issuecomme > nt-480236238 > <https://github.com/spring-projects/spring-boot/issues/16450#issuecomment-480236238> > , > > > > > we can't configured thread's "keep alive time" via "maxIdleTime" > > parameter, "keep alive time" value is hard coded as 60s via > > https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80f40 > adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884 > <https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80f40adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884> > , > > It > > > is only hard-coded if you use the internal, default Executor. You > can instantiate your own Executor with whatever settings you wish. > > It's a bad name for that setting, but this is how long "excess" > threads will live when they are not being used. > > > I found 60s "keep alive time" sometimes take effect, some times it > > doesn't take effect. Could u please kindly help to review my > > following two cases and kindly provide explanation? Really > > appreciate ur help in advance! > > > > *Case 1 (60s "keep alive time" DOESN'T take effect):* API latency: > > _100ms_ Test step: run API with 800 concurrent threads for 1 > > minutes, then run API with 10 concurrent threads for about 1 hour. > > As we can see from following graph, after BusyThreads reduced from > > ~800 to 10, CurrentThreadsCount remains at 800 for following 1 hour > > (60s "keep alive time" DOESN'T take effect). After test stopped, > > CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > > image.png > > Your images have been stripped from the mailing list. Find another way > to describe your problem. > > When you say "X concurrent threads", how often are requests being > made? Constantly? So you are sending requests as fast as possible with > c=10? > > I haven't read the code in detail, but I'm guessing that the thread > pool uses a queue and not a stack of threads, so each thread gets > used, repeatedly, in order of availability. That means that if you > keep making requests, you'll keep hitting *all* the threads in the > queue and not just the same 10 over and over again. So they never time > out. > > > *Case 2 (60s "keep alive time" DOES take effect):* API latency: > > _10s_ Test step: run API with 800 concurrent threads for 1 minutes, > > then run API with 10 concurrent threads for about 1 hour. As we can > > see from following graph, after BusyThreads reduced from ~800 to > > 10, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > > 60s "keep alive time" DOES take effect) > > Note that Tomcat's thread pool is just a wrapper around Java's > ThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle > events, etc. > > So if the pool isn't behaving as you'd like it, you'll need to file a > but against the Java API and not Tomcat. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl28NzYACgkQHPApP6U8 > pFjcRxAApIe9WPrO43rIn+8TZ/KBncZbw2ZQr/nEew1pS7xdRFl2LVn/gMpuYaIe > 78rF/3M9S0aYcG93vaqzn1+BZXW5EI9EINo+UG3E17ZYeD162Cpl2Q7aqaB/Te0j > QR/JHIv31TAUpH39VLEpzfk/d1uct7oVZDq4P3kUjjAFwAo2G0useiHjokXtdIEm > 3wXL1e8ChpvdP8RfrPdeATdGtEvGh0zNDW2Qjce+7R5LoC55UpHqJfB+p8BB6nV/ > W6Jdp8CN8pVp+wROMMyK3HFvubFqSPcrKGURCmwKMH/QgRfRSTNpIfXYpubfOOqm > EF0XxvRc2s/x6ZqRrfnbkunqqmb0h35SXPaWl1RJWpe/cAAaHi0DGORorbDZfnff > agzNvl7Wl0/6HL09CXr2PHU6ZQGytSYbItVAjEHqLKhbYW4pLKviLYB84ZRiEc5N > 2ZA2ZE9VKWQRgu1kS25U4c5R7Zgy5oVAAIPLzNqEdcqu2dXSsZZeW4sJutwjioOL > pia5qqRcotdDPxATqv0Eo75cqvvgE5WeWZ/tMb2sVia85UPRL/cJCgrc/+HmYPmb > JRzhobGhQ7WA33yqRfvBdcJ5HIGe2aU4o06VoAv6tHXPldjD4jQ/YHyyicP+bj6E > wswEM7oIAIU8+R7JFp1Lhv6ZMuLlKohDmOu2bubhAgweSrAQ8jY= > =901h > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
