On Fri, Oct 25, 2013 at 10:30 AM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----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...
Wouldn't TomEE still depend on Apache/Tomcat Taglibs ? > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
