Web app investigation part 2 – StringTemplate

Last updated on Tuesday, January 30, 2007

In a recent post I talked about implementing a very simple web app with different frameworks and why JSF isn’t for me. This post will describe my experience with StringTemplate. I also give some informal performance numbers.

Servlet

After getting the JSF implementation working, including validation and enough i18n to get the hang of it, I started on a bare bones no framework servlet implementation with the same functionality. Servlets are very simple and easy to understand. You can do things anyway you want and there in lies the problem. How should I do things? Here I got sidetracked searching for information on web best practices. I finally understood the wisdom of doing a redirect after POST and its not just about the double submit problem. I also did tons of reading about REST. I like thinking of the application in terms of its resources and creating friendly URLs. I’m still struggling with where to put conversational state.

I had to force myself to stop reading and get back to coding. I got to rediscover how hard (as in tedious and annoying) it is to type XHTML output into Java code. Good thing this is a very simple web app! I was starting to look forward to using StringTemplate.

With the servlet version I was responsible for making sure the XHTML was valid. With JSF I was pleased to see that the facelet tags did a good job at generating valid XHTML. I implemented the POST redirect GET (PRG) pattern for the servlet but never went back to the JSF version to figure out how to do it there. I think that since the PRG pattern is so important that a framework should somehow make it automatic. The frameworks I know of allow you to redirect but don’t give any guidance on when to do it.

StringTemplate and Servlet

StringTemplate was a lot of fun to learn. A while back I had read “Enforcing Strict Model-View Separation in Template Engines” and looked a little at an older (2.x) version but I didn’t get to put it to use then. Now version 3.0 is out so I started with that. There were a number of new features and the documentation is also improved. The StringTemplate version of the application is mostly the same as the servlet version but with the XHTML generation done with templates. StringTemplate is an interpreted language. At first this was a concern but so far it seems fast enough. In theory there is no reason why a StringTemplate couldn’t be compiled. Being interpreted makes for fast code-test iterations because you can set it to not cache templates, just make a change to the template and hit refresh in your browser.

StringTemplate is still evolving and improving. One thing I like about it is the code is small, and easy to find your way around in. I have made a few changes and bug fixes with no problems.

Testing

Once I got the StringTemplate version working the same as the others I did some informal testing to compare the performance of each. This gave me a chance to try out the Eclipse Test and Performance Tools Platform (TPTP) (Installing TPTP is required when installing the Eclipse Web Tools). When I first tried to use it, it worked fine for the sample and Java applications but not for web apps. After a while I figured out that the agent controller needs to be downloaded and installed separately. It doesn’t actually need to be running if the server under test is on the same machine but a critical install step is to add the agent controller bin directory to the PATH.

I used the TPTP profiler to look at memory usage and execution times for each of the implementations (JSF, StringTemplate, and Servlet). I just did a GET of the first page.

To get the client timings I used the TPTP URL test. I learned for this test you don’t really need the artifact, location or deployment entities. I found TPTP URL test to be somewhat similar to Jmeter in that the tests can be edited graphically. One difference is TPTP tests are compiled into JUnit tests. The documentation on TPTP is a little lacking and I have lots more to learn in this area.

Test Results

I used a single client making a GET request to the first page 500 times with no wait between requests. I repeated the test 5 times. I used a get because I was interested in the framework and rendering overhead not any business logic (which my simple app doesn’t have much of anyway).

• Servlet: avg 4.2 seconds for 500 requests
• StringTemplate: avg 9.2 seconds for 500 requests
• JSF: avg 13 seconds for 500 requests

It is no surprise that raw servlet had the best performance. When I first ran the tests with StringTemplate it took longer than JSF. I had forgot to turn on caching of templates. I also found that it is better to call the StringTemplate write method when writing to a stream rather than calling StringTemplate toString and then writing the string to the stream.

The page sizes in bytes are:

• Servlet: 1,438
• StringTemplate: 1,965
• JSF: 4,772

The difference between Servlet and StringTemplate is in extra whitespace. Again the JSF file is so huge because of the view state.

I spent some time poking around with the performance monitoring tools looking at execution times and memory usage. For StringTemplate the processing can be generally characterized as lots of quick method calls and lots of temporary objects created then collected. No single method stood out as taking substantially more time than the others. Not much time was spent in reflection, which makes sense since most of the template expressions were with maps and only two used properties.

For the JSF implementation there is very little of my code; just a model bean. Everything happens in faces/facelet code. There seems to be a large cost to the first page access so I got the page once before starting the profiling. It seems to me that JSF is very busy (in terms of number of calls) building the component tree. Like StringTemplate many objects are created and then collected although not quite as many. JSF deals with larger grained component objects that represent the view structure whereas StringTemplate has an AST structure of smaller grained objects that represent the fragments of text and attribute expressions in the templates.

Summary

I really like working with Servlet and StringTemplate. StringTemplate provides a very nice way to generate the web UI and with Servlet I have the freedom to do things the way I want.