Unscientific Jetty versus Glassfish for REST

This post was too unscientific and was updated. Jetty is an excellent container and the container of choice whenever I do something with servlets. Ever since we’ve developed SnipSnap some years ago I love Jetty. Glassfish has some very promising features like the admin console and I´m eager to try Glassfish in a project sometimes in the future.

Reading about another story of Rails performance, I grabbed JMeter to benchmark one of my current projects. Not so much as a comparison for Ruby – which managed 320 requests per second – but more as a comparison of Jetty and Glassfish.

The application is a small REST server which reads data from a JDBM storage, transforms it with my own framework to Json and delivers the result with Jersey.

Both servers were started with their default configuration through their maven plugins (wonderful easy to use mvn glassfish:run). Unscientific as it may be, the numbers are:

  • around 1000 requests/sec for both containers

Both with 200 threads and 50 requests per thread. Both numbers are great for my MacBookPro and good enough for me. They also are so close to each other so they are not a deciding factor for either Glassfish or Jetty. At the risk of comparing apples to oranges I have no fear of deploying this to a production system and scaling cheap (and even better with E-Tag caching), keeping in mind the requests per second with 25 servers in the Rails example.

Thanks for listening.

Update:: Another Rails application which thinks it did scale – at least with Merb, to 650k page views per day, well that’s “650K hits per day is ‘only’ around 8 per second (assumed a 20 hour day to spike it a little). This doesnt actual seem all that much?”.

The JMeter speed and 1000req/sec (for an admittantly simple REST GET) results in … 86.4M requests per day. Uh. On my MacBookPro.

Problems with Jersey, REST, JSON and UTF-8 [Update]

UTF-8 is always a problem. Unbelievable. 2008 and we still haven’t fixed this. One of my current projects is a Javascript frontend with a REST backend. The backend stores to MySQL (a famous UTF-8 trouble maker) and creates JSON to REST calls. The problems starts with UTF-8 characters. Somewhere in the callchain – as always – characters don’t get correctly written. MySQL and the JDBC driver should work, the JSP page is UTF-8 (@page and meta-equiv), jQuery – which does the AJAX – and JS do know UTF-8 and Jersey should be UTF-8 too. But with some experiments now I’m quite sure that Jersey (JSR 311 REST framework) is to blame. I’m not sure how to specify UTF-8, this

doesn’t help. Funny, every major project with several frameworks along the call chain and several languages (JS, C, Java) makes UTF-8 problems somehow. I’m so fed up with this, it’s 2008.

Update: Jersey uses InputStreams for all encodings, especially StringProvider is relevant to me (se above). Does this work with Unicode?

Experiments for nicely generating JSON

I’ve been experimenting with ways to nicely generate JSON. There are many ways to generate JSON in Java, like XStream with Jettison, with JAXB or directly with REST API implementation Jersey. Often you don’t want to serialize objects or work mith maps though. Taking code from “The best Markup Builder I could build in Java” I’ve tried a builder approach.

The generated JSON would be

To create nodes for a JSON tree I first tried a node function. But having lots of node calls makes the code quite unreadable. Luckily Java allows $ as a method name. Using $ makes the code much more readable. The List object creates a list of nodes, taking input from a collection, Iterable or Iterator and calling item() for every element.

To reuse generation code one can create semantic methods like an items method:

The nice thing is, with another render mechanism the tree of nodes can also be rendered to XML with a toXml() method, if XML works better for some REST calls. Next thing to add is support for XStream and Jettison to mix serialization in e.g. $("employee", employeePOJO); and experiment on how to make the code even nicer and shorter.

I also wonder how to remove the toJson() call with Jersey and to use a Jersey writer. Any ideas?

Thanks for listening.