We use LVS+ldirectord. It does not provide the kind of logs you're referring to.
> -----Original Message----- > From: Martin Grigorov <mgrigo...@apache.org> > Sent: Saturday, September 12, 2020 12:03 AM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Tomcat Processing Timer Question > > 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/ > > > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9aiH4ACgkQHPApP6 > U8 > > > pFiFfBAAvuUbRXK+iDDy7lLsw6eplMFrXXDbkxzwtSNafvdGlDWmcPWwdazZw > hQ+ > > > TJ0pzkUwf3/RBslu/oORJYelYKhpUJLodj0Y85ZtbuKBcU2JpKk1uueJ/aqnmVFK > > > 9yep3ReYdggEXQ3JNb1VeI4ASdEhFWoFw8pc6DAcJZ4K2JaUtGKrtoWG8n+oE > Xos > > > kmthl9Dm9ge3edLimd7TPTx11iODi6pX3ddJ+uRh7qmvXZp4wVyX8W+hkKiOh > UQM > > > hokUd8RruXQm6wut5m+JSO6eLHqkKUBiLspzlz1x/Y4cuaqAlC8Pl5y9NFTuLK3 > e > > > gFJeDmBUthN2y5h9KNKW5r+Gf9bKpuv1+kw7CIaNoFv2JxCGTmfL3VKM+Bp/ > rh7J > > > 1SbshsTW6ffo5hKRNJUJKvxry3uUvzrss0AYe338tJ1QA+sHuXHsN8ZVtY3b+51 > O > > > HBOYf3pgIPsSd6zXkjaSRoOAhVc9G5sbJHx8ycQt+yAyVvXEUwrqeeRbsJeADk > 2s > > > reaizm9WvO2kHSqP93ANNYe1QJ+rw9b5og0uoCE8x9eO+czRHbJ7LFF6/rvX+6 > Pn > > 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. > > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
