Chris, thank you for your reply.
On 8/6/14, 4:49 AM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Peter, > >On 8/5/14, 7:54 PM, Peter Rifel wrote: >> I am in the process of upgrading from Tomcat 7.0.54 to Tomcat 8.0.9 >> and am seeing some performance degradation in my webapp. >> >> Configuration info: >> >> Ubuntu 14.04.1 LTS java version "1.8.0_11" Java(TM) SE Runtime >> Environment (build 1.8.0_11-b12) Java HotSpot(TM) 64-Bit Server VM >> (build 25.11-b03, mixed mode) >> >> Both versions of tomcat use the APR Connector with TC Native >> 1.1.31 statically linked against APR 1.5.1 and OpenSSL 1.0.1h >> >> >> I'm running identical requests to identical web apps between these >> tomcats and in Tomcat 8 I'm seeing an ~20% response time increase >> and as such a similar reqs / sec decrease. After using VisualVM to >> profile the application I've narrowed it down to the JRE's JAXP >> library taking significantly longer to create its xml validation >> "SchemaFactory" which doesn't make sense to me because I'm using >> the same JRE in both tests. > >To me, this suggests other factors that haven't been controlled, like >GC activity or something else. Are you sure you have a good >steady-state test? > >Any chance you could create a single SchemaFactory object and then >synchronize access to it? It might reduce contention. Another >possibility is to use a ThreadLocal (which has its own dangers). I have ran the tests again on bare metal hardware and the results are consistent. GC activity looks the same as well. I'm experimenting with different methods of avoiding SchemaFactory construction and will probably end up creating a self-managed pool of them to be shared across threads. I experimented with one synchronized object and the results diminished under heavy loads. > >> I know that the Resources implementation was overhauled in Tomcat 8 >> so is there any possibility that this could be a side effect? For >> a better idea of what I'm talking about, see the below VisualVM >> screenshots of a profiling snapshot's call tree: >> >> >> Tomcat 7 - http://i.imgur.com/pbX5xBG.jpg Notice how the time spent >> in the javax.xml.validation.* methods is <6% >> >> Tomcat 8 - http://i.imgur.com/Txv20lg.jpg Notice how the time spent >> in these methods is significantly higher. > >Does the "validation" time include loading the schema itself from >wherever it is located? Validation time does not include loading the schema file, only specifying the schema language which to my knowledge doesn't involve any external I/O. Loading the schema file from the WEB-INF directory actually takes negligible time. I would've thought the opposite, which is why I'm confused by this. > >> Again, I'm confused as to how the performance of the JRE's library >> changes between tomcat versions, can anyone explain this to me or >> point me in the right direction on where to look? Is it as simple >> as a config change or will it require a java code change? The >> XmlUtils.validate method you see in the screenshot is simply the >> following: >> >> javax.xml.validation.SchemaFactory factory = >> SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema";); >> >> Here are the Tomcat configurations: >> >> >> Tomcat 8 server.xml: http://pastebin.com/Tn3d6bXd Tomcat 8 >> context.xml: http://pastebin.com/reuJCGNq >> >> Tomcat 7 server.xml: http://pastebin.com/Kq6SfFd0 Tomcat 7 >> context.xml: http://pastebin.com/vdp0PGPh >> >> >> Does anyone have any idea why this might be performing so >> differently between versions of tomcat? Could it be a bug in the >> JRE? I can try and provide test code for repro if it helps. > >- -chris >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1 >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQIcBAEBCAAGBQJT4hZQAAoJEBzwKT+lPKRYJjkP/AzqWNqqEUask7/uF+tuQX13 >jWhEVww7b7pMQjyoVqvMA1J4VoUTLBM1je6wJpBaIVndq8MIBu6vuO6rpZl3UH6N >/SpljKB4HdovwUIUAPtJKTV5bQExGGIgWUENYS6fA1YPOnI9hS5rShrs/YxMnjnW >csrR+UVW20TwucHvpsqoEPVFszD5j8WIg08tebKSEscAWqoKpShEpNAuSefh4AKZ >R3md0Zmd0Qevpn/zzusFKaVqb6LmCwLUfTbtmpCX/irK3wj800GXQT2WECrW3il8 >mL9142A8FhtqsCKSh+A3mQukfaf5SZqJ5JPyKGAFNhceA4fgd3Sdb4pCKvb7uoav >NJda7luZaqRUcgm4CX6rNCVwf6aWccu3oO7L+tG7G8OHi6KptrZ6VOdrBb9peXvB >9pFddcxxBc1Th5mANGLFCC7JKc4Sq1VeG8CEIWPcl0JB/bKT2jODabcy6GQ9jpp6 >HmTX8gRoc5sDpcPxq/vr+dcW7dSyAK9RYp7hYzUJaO13o5pCINcjzYdVBECLCKoU >Fyga1Re9v02CfL0aAUXAWgOWW7RNBm2ehBX1yqHq4Di/y5I84tJQxqcX9Amhss/R >HCfcT1FTIs671zYZOh/w3JTmkQC4BgPEEev9WM1XTel9y77x/QmDwpPzEvZT2fgS >4lvTEwCzxmgC4HjFVrxh >=A0ue >-----END PGP SIGNATURE----- > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org > Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
