Hi Remy, Thanks for the reply,
As you mention below points "There's a problem only if things are blocked improperly, for example if the client is correctly reading the data and/or there's no network backlog. Also the timeout configured on the connector must be respected by the operation." 1. how can we check the network backlog or data read/write not working properly, if any tool pls let us know 2. how can we set connector timeout. Thanks and Regards, Rajendra Rathore 9922701491 -----Original Message----- From: Rémy Maucherat <r...@apache.org> Sent: Tuesday, January 7, 2020 4:11 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API External email from: users-return-269207-rarathore=ptc....@tomcat.apache.org On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra <rarath...@ptc.com> wrote: > Hi Rémy/ Christopher, > > It will stuck there for 10-15 minutes, so it will take time to load > simple Web UI, there is no WebSocket call. I am giving you one of the > sample where it will take 90% time in write operation, sometime it will reach > to 100%. > > > | | > > O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:1331) > count=1669(%92.877) > | | > > O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase > .java:385) > count=1669(%92.877) > | | > > O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWra > pperBase.java:462) > count=1669(%92.877) > | | > > O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBa > se.java:726) > count=1669(%92.877) > | | > > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioE > ndpoint.java:1316) > count=1669(%92.877) > | | > > O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.jav > a:157) > count=1669(%92.877) > | | > > O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSele > ctor.java:114) > count=1667(%92.766) > | | > | > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWriteLa > tch(NioEndpoint.java:1160) > count=1667(%92.766) > | | > | > O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1157) > count=1667(%92.766) > | | > | > O-java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > count=1667(%92.766) > > It's a normal blocking write, and the await does not consume CPU (it sits there however and a profiler will count that but it doesn't matter). There's a problem only if things are blocked improperly, for example if the client is correctly reading the data and/or there's no network backlog. Also the timeout configured on the connector must be respected by the operation. Rémy
