Skip to content

Posts tagged ‘tomcat’

21
Jun

Why are JSPs so slow? (Tomcat 7 vs. Apache)

It would be unreasonable to expect JSPs to be served at the same rate as static files. Even after being compiled, requests to JSPs must pass through layers of servlet container code, not to mention the latency of the JSP code itself. However, the difference between static files vs. JSP is much larger than I would have expected.

I ran a test on a 6KB HTML file using Apache Benchmark on my Dell Inspiron N7010 laptop, using 1,000 requests @ 10 concurrent requests.  I also created a JSP by pasting the same HTML into a file, adding only a few dynamic elements: outputting the of the host name, port, and app URI.  No calls to any beans, JDBC, or other potentially slow resources were made.  Default installations were used for both Apache and Tomcat 7.  The results were stark:

  • Apache static HTML file: 971.25 pages/second (blazin’)
  • Tomcat 7 JSP file: 92.5 pages/second

As you can see, the JSP is not merely slower.  It is a full order of magnitude slower.  Because the dynamic content is trivial in this test file, the performance of the servlet container fully accounts for this difference.

I thought I’d also test loading the JSP through Apache using mod_jk to see what kind of performance penalty this imparts.  Results:

  • Tomcat 7 JSP file via Apache mod_jk: 74.80 pages/second

So in this test case, there was a 19% performance penalty fronting Tomcat with Apache.  Of course speed is not the only consideration when evaluating using this type of setup, but it is something to weigh against other concerns.

There is also a debate about whether Tomcat or Apache is faster at serving static files.  This test is only one data point, but Apache easily wins here.  Tomcat serving the static 6KB file:

  • Tomcat 7 static HTML file: 203.5 pages/second

In this test, Apache was nearly five times faster at serving this file (though more than twice as fast compared to the JSP version).

And now, for people who like charts. =)

Chart shows Apache/HTML easily bests Tomcat/JSP

12
May

Disable URL session IDs (JSESSIONID) in Tomcat 7, Glassfish v3

URL-based session tracking is intended for web clients that do not support session cookies. Every browser worth mentioning supports these cookies, and almost nobody surfs with them disabled. Most web sites either state explicitly or assume that a user’s browser supports session cookies. URL rewriting schemes that add the session ID as a parameter on every URL thus provide very little benefit, if any at all. Session IDs showing up in URLs is just bad form, and may confuse search engine spiders. Thankfully the Servlet 3.0 standard gives you two ways to disable URL session rewriting. This works in Tomcat 7, Glassfish v3, and any other Servlet 3.0-compliant servlet container.

First, you can add this to your web.xml web-app config:

<session-config> 
    <tracking-mode>COOKIE</tracking-mode> 
</session-config>

Or programmatically, you can use:

servletContext.setSessionTrackingModes(EnumSet.of(SessionTrackingMode.COOKIE));

I’ve used the web.xml method in Tomcat 7, and it works. No jsessionid in the URLs when using <c:url …> in my JSPs.