-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Stephen,
On 10/25/13, 9:13 AM, Stephen More wrote: > On Fri, Oct 25, 2013 at 5:14 AM, Felix Schumacher > <felix.schumac...@internetallee.de> wrote: >> On Do, 2013-10-24 at 11:29 -0400, Stephen More wrote: >>> I came across this paper by Peter Lin ( >>> http://tomcat.apache.org/articles/performance.pdf ). In a >>> simple xml addressbook war he summarizes how different >>> variables affect the speed of the application. In one test he >>> compares: Sun X1 400mhz Ultra Sparc IIe - 5 requests/sec AMD >>> 2ghz XP - 25 request/sec It appears that both used Tomcat >>> 4.1.19 and Sun Jdk1.4.1_01 >>> >>> In an attempt to see what todays numbers look like I rebuilt >>> the war ( svn co >>> https://maven-examples.googlecode.com/svn/trunk/addrbook ) and >>> deployed in my environment Core i7-3720 QM @ 2.60 GHz SSD disk >>> java version "1.7.0_45" apache-tomcat-7.0.42 >>> >>> package the war - mvn package execute jmeter - mvn verify >>> >>> Jmeter shows my Throughput of 2.2 requests/sec ! With all the >>> advances over the years ( or overhead ) are we just slowing >>> down or are one of our results flawed ? ( I am running in >>> VirtualBox - I think this would slow some things down - but not >>> this much. ) >>> >>> Are others seeing similar results ? >> I get almost the same throughput, but I don't believe it is >> tomcats fault (well not directly). >> >> If you look at the stacktraces while doing the jmeter test, you >> will see very often a stack trace like this: >> >> "http-nio-8080-exec-8" daemon prio=10 tid=0x00007fb83400b800 >> nid=0x2511 runnable [0x00007fb88847b000] java.lang.Thread.State: >> RUNNABLE at >> com.sun.org.apache.xml.internal.dtm.ref.ExpandedNameTable.getExpandedTypeID(ExpandedNameTable.java:160) >> >> at >> com.sun.org.apache.xml.internal.dtm.ref.dom2dtm.DOM2DTM.addNode(DOM2DTM.java:293) >> >> at >> com.sun.org.apache.xml.internal.dtm.ref.dom2dtm.DOM2DTM.nextNode(DOM2DTM.java:524) >> >> at >> com.sun.org.apache.xml.internal.dtm.ref.dom2dtm.DOM2DTM.getHandleFromNode(DOM2DTM.java:680) >> >> at >> com.sun.org.apache.xml.internal.dtm.ref.dom2dtm.DOM2DTM.getHandleOfNode(DOM2DTM.java:732) >> >> at >> com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault.getDTMHandleFromNode(DTMManagerDefault.java:576) >> >> - - locked <0x00000000f20af5e8> (a >> com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault) at >> com.sun.org.apache.xpath.internal.XPathContext.getDTMHandleFromNode(XPathContext.java:188) >> >> at com.sun.org.apache.xpath.internal.XPath.execute(XPath.java:305) >> at >> org.apache.taglibs.standard.tag.common.xml.JSTLXPathImpl.eval(JSTLXPathImpl.java:222) >> >> at >> org.apache.taglibs.standard.tag.common.xml.JSTLXPathImpl.evaluate(JSTLXPathImpl.java:287) >> >> at >> org.apache.taglibs.standard.tag.common.xml.JSTLXPathImpl.evaluate(JSTLXPathImpl.java:385) >> >> at >> org.apache.taglibs.standard.tag.common.xml.XPathUtil.valueOf(XPathUtil.java:213) >> >> at >> org.apache.taglibs.standard.tag.common.xml.ExprSupport.doStartTag(ExprSupport.java:73) >> >> at >> org.apache.taglibs.standard.tag.el.xml.ExprTag.doStartTag(ExprTag.java:71) >> >> at >> org.apache.jsp.simple_005f100_jsp._jspx_meth_x_005fout_005f0(simple_005f100_jsp.java:411) >> >> at >> org.apache.jsp.simple_005f100_jsp._jspx_meth_x_005fforEach_005f1(simple_005f100_jsp.java:377) >> >> at >> org.apache.jsp.simple_005f100_jsp._jspx_meth_x_005fforEach_005f0(simple_005f100_jsp.java:336) >> >> at >> org.apache.jsp.simple_005f100_jsp._jspService(simple_005f100_jsp.java:118) >> >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >> >> >> If you search for >> "com.sun.org.apache.xpath.internal.XPathContext.getDTMHandleFromNode >> >> slow jstl" you will get to a bugzilla entry for jstl from >> https://issues.apache.org/bugzilla/show_bug.cgi?id=27717 which >> is closed. >> >> That bugentry suggested, that an xslt-Transfrom would be faster, >> than using <x:forEach> and if you try to replace the forEach loop >> with a transform, you will get better response times (on my >> system throughput went up from 1.6 r/s to 23.6 r/s for one >> thread. (I try to attach my changes, but sometimes the list >> strips attachements...) >> >> So either the bug has been reintroduced into jstl, or it is >> really slow and should be avoided. > > Felix - thanks for your help. The current jstl version in the > pom.xml is 1.2 which looks like it was released in July 2006. Bug > 27717 was not fixed until December 2010. I built and installed from > source: > http://svn.apache.org/repos/asf//tomcat/taglibs/standard/trunk/ > and now I am getting 44 r/s !! > > I now have 2 questions: 1 - When is the expected release of > org.apache.taglibs taglibs-standard-impl ? I believe Jeremy just recently (2013-09-14) rolled a 1.2.0-RC1 release, but it didn't get enough votes for an actual release. I think this will be one last "hurrah" before the project closes-down. I thought everyone had moved from Apache/Tomcat Taglibs over to Glassfish's JSTL implementation... it seems to be the industry standard these days. Can you try with the GF version? >> All in all I think you should do your performance tests with a >> more modern benchmark. It would be best, if it would expose your >> expected workload and not someone others. > > 2 - What modern benchmark would you recommend for tomcat that > includes published results ? The problem with benchmarks is that you can really only micro-benchmark things. After that, everything becomes somewhat subjective because performance really has more to do with usage patterns and application architecture. Any micro-benchmark can tell you how well Tomcat (or any container) is getting out of the way: basically shaving microseconds off of response times. The only way to double your transaction rate is to make your application faster... the containers are already pretty slim, except where it comes to experimental features. For instance, if you were to compare Tomcat's Websocket implementation against, say, Jetty, Resin, etc. you might get wildly differing results. If you were to compare the basic HTTP implementation against a static document or maybe a simple JSP, I think you'd find that all containers performed roughly equivalently. In many cases, I think you'd find that today's containers performed less well than older containers (adjusted for hardware inflation, of course). The reason is that today's containers are more complicated, have more features, more security checks, etc. Tomcat 3.3 didn't have to check for HTTP-upgrade headers for instance, so that was one less thing the container had to do. Certain benchmarks are useful, but most are useless. If you want to find out how a container "performs" in a way that has meaning to you, then you should really write a good JMeter (or whatever) script that exercised /your/ webapp and then run it against all contenders. Nothing else really matters. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSaoB2AAoJEBzwKT+lPKRY3K0P/0GGPfAh0u0/qlVeCoogcxlt R3T8bgCLfUboRm4QtE3qfY+JIqZh627bsiqJRkWwwKMNcIwbvnVHr5nyGLxr/yyj kRv5LQREKl+TLj55z0EndWmWjT/bp3s7n6RPftn3LhWPrRpiJpOKR4knLa4NM0AP 8FN9AYsHiopju7at2TfIpBm+NFDJ4eyeS8cs7J6xjhKC+sOzpJNE8I73C26paA7V 220igj8F48RUYK8/Hwo1lNH02EA+lyM8LiOEAAjAeuwbtMef0yEeIfDvxte6T6xD R7Wb8YUbZ6cAxpGSFRO9jP9N7XZ1hkdqN6872iBLR5eS7kbGeaUGzwq5L+PXcJNA 4mnjCMXGF6c8stU7hcnQJ7bCIzSkB/UKiYE2lgSOeoXqtVSH84lsWPpFiR7XNOu2 dtx1eekIl8V/8w8PbM8EOSIZ4wiST3uFvAIafnj/aIEpLS2K1WyBdTg6bweQxHi0 af4GC8f6hsNgo7UlLX4z9s+lflqWypwgW7wEyjKOxy+908lXHLEx0x6C6bUzHvgG hx5e6pjucETRtbTNVbohwwEYJ6obfYsrA+M8X/HlnB/phge6PTQzAVBHjamkReWC 9NVEIVcbGx8G+KD1daaC3dPDuSVbp0pLU/R6JLA0LrnG24xM2LB4+fjG5Wt+3ALn pFiAHw7I9ZZ/aS+KxgD8 =qgxX -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
