https://bz.apache.org/bugzilla/show_bug.cgi?id=58950
--- Comment #9 from Philippe Mouawad <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
