https://bz.apache.org/bugzilla/show_bug.cgi?id=58950
--- Comment #10 from Philippe Mouawad <[email protected]> --- (In reply to Philippe Mouawad from comment #9) > (In reply to Philippe Mouawad from comment #6) > > Created attachment 33575 [details] > > Test Plan that reproduces the issues with a Tomcat 8 > > > > Hi, > > I have a strange issue which also occurs with 2.13 by the way. > > > > Tomcat configuration: > > > > apache-tomcat-8.0.30/webapps/ROOT/WEB-INF/web.xml contains: > > <session-config> > > <session-timeout>1</session-timeout> > > </session-config> > > > > setenv.sh in tomcat/bin contains: > > export CATALINA_OPTS="-Xmx1024m -Xms1024m" > > > > > > server.xml: > > <Connector port="8080" protocol="HTTP/1.1" > > connectionTimeout="20000" > > enableLookups="false" > > keepAliveTimeout="2000" > > minSpareThreads="25" > > compression="off" > > redirectPort="8443" /> > > > > > > > > When I run the test, I get a boost in CPU, then a pause (a thread dump shows > > threads stuck: > > java.lang.Thread.State: RUNNABLE > > at java.net.PlainSocketImpl.socketConnect(Native Method) > > at > > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) > > - locked <0x00000007a2804870> (a java.net.SocksSocketImpl) > > > > > > Then after some time a new peak in CPU and then the pause.... > > > > > > JMeter config at defaults and Java options: > > -server -Xms1024m -Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xss256k > > -Dcom.sun.management.jmxremote.port=3333 > > -Dcom.sun.management.jmxremote.authenticate=false > > -Dcom.sun.management.jmxremote.ssl=false -XX:+UseThreadPriorities > > -XX:ThreadPriorityPolicy=42 -verbose:gc -XX:+PrintGCDetails > > -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails > > -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime > > -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintHeapAtGC > > -XX:+PrintGCCause -Xloggc:/data/jmeter/verbose-3.0.log > > -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false > > > > > > It could be my machine TCP configuration but could somebody check on Linux > > machine ? > > Thanks > > Hello, > The issue was due to ephemeral ports saturation. > After fixing my machine configuration, I was able to run the test in better > conditions. > On Mac OSX, I setup socket reuse time to 1s (it was 15s before) and the CPU > drop falled down to 1s range vs 15s range before. > > So this benchmark, confirms what Bug 59034 mentions regarding management of > Connections when Parallel download is used for embedded resources. > But there are good news with it, with 15 threads we make 138% more samples > with 3.0 than with 2.13 thanks to fixing of Bug 57804. I meant fixing of Bug 58099 (not Bug 57804) -- You are receiving this mail because: You are the assignee for the bug.
