Hi, On Sat, Sep 12, 2020, 02:57 Eric Robinson <eric.robin...@psmnv.com> wrote:
> I'm not sure what you mean by measuring at the load balancer level. We're > using the jasper logs and those only exist on the tomcat server itself. I > must be misunderstanding your meaning. > He meant to use the LB's logs for the same. What software do you use for load balancing? > Get Outlook for Android<https://aka.ms/ghei36> > > ________________________________ > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Thursday, September 10, 2020 3:11:43 PM > To: users@tomcat.apache.org <users@tomcat.apache.org> > Subject: Re: Tomcat Processing Timer Question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Eric, > > On 9/10/20 15:29, Eric Robinson wrote: > > Chris -- > > > > > >> You should also look at worker-thread availability. When you see > >> these "high latency" (which is usually a term reserved for I/O > >> characterization) events, do you have:>> 1. Available worker > >> threads (from the executor thread pool) 2. Any other > >> shared/limited resource (e.g. DB connection pool) > >> > > > > Good thought. I should mention that the hosted application is > > canned, and is the same for all tomcat instances, with only minor > > variations in version between them. User workflow is also similar. > > Over the years we've developed a good feel for expected > > performance and resource utilization based on the user count per > > instance. So when one instance exhibits anomalous performance, we > > tend to go right to networking issues. > > > >> Also, are you seeing the otherwise unexpected slowness on each > >> Tomcat node, or are you seeing it at the > >> load-balancer/multiplexer level? > >> > > > > We run multi-tenanted servers, with many instances of tomcat on > > each server. We've never seen issues at the load-balancer. > > What I mean is, are you measuring the request at the Tomcat level, or at > the load-balancer level? If you are watching at the lb, then your lb > might pick a "busy" Tomcat and the request has to "wait in line" before > processing even begins. If you sample at the Tomcat level, you'll see no > discernible slowdown because the time "waiting in line" does not count. > > > Very occasionally, there might be a problem at the server level. > > When that happens, all instances on that server may become > > sluggish. What I'm talking about in this thread are cases where > > only one instance on a server is showing slowness in its jasper > > logs. Also, we typically do not see the same slowness when we test > > the application locally from the same network. I've had my eye on > > TCP retransmits as a possible culprit for a while, but I just > > didn't know for sure if my understanding of the tomcat processing > > timer is correct. > I hope we've cleared that up for you, then. > > You might also want to read about "buffer bloat" if you aren't already > familiar with that term. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9aiH4ACgkQHPApP6U8 > pFiFfBAAvuUbRXK+iDDy7lLsw6eplMFrXXDbkxzwtSNafvdGlDWmcPWwdazZwhQ+ > TJ0pzkUwf3/RBslu/oORJYelYKhpUJLodj0Y85ZtbuKBcU2JpKk1uueJ/aqnmVFK > 9yep3ReYdggEXQ3JNb1VeI4ASdEhFWoFw8pc6DAcJZ4K2JaUtGKrtoWG8n+oEXos > kmthl9Dm9ge3edLimd7TPTx11iODi6pX3ddJ+uRh7qmvXZp4wVyX8W+hkKiOhUQM > hokUd8RruXQm6wut5m+JSO6eLHqkKUBiLspzlz1x/Y4cuaqAlC8Pl5y9NFTuLK3e > gFJeDmBUthN2y5h9KNKW5r+Gf9bKpuv1+kw7CIaNoFv2JxCGTmfL3VKM+Bp/rh7J > 1SbshsTW6ffo5hKRNJUJKvxry3uUvzrss0AYe338tJ1QA+sHuXHsN8ZVtY3b+51O > HBOYf3pgIPsSd6zXkjaSRoOAhVc9G5sbJHx8ycQt+yAyVvXEUwrqeeRbsJeADk2s > reaizm9WvO2kHSqP93ANNYe1QJ+rw9b5og0uoCE8x9eO+czRHbJ7LFF6/rvX+6Pn > TIYB7AHyV8P3PHpHtBGIgaNfnvIYbqx/hzxJpLlpNEcS2zARfi1YCnuNtbiH0KU/ > AKkBx5FnZvwclCA3qK2oqBnSEcBUFz2yobq4wAy//qwgL2gEFNc= > =mcpm > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Disclaimer : This email and any files transmitted with it are confidential > and intended solely for intended recipients. If you are not the named > addressee you should not disseminate, distribute, copy or alter this email. > Any views or opinions presented in this email are solely those of the > author and might not represent those of Physician Select Management. > Warning: Although Physician Select Management has taken reasonable > precautions to ensure no viruses are present in this email, the company > cannot accept responsibility for any loss or damage arising from the use of > this email or attachments. >
