Code Monkeyism

Programming is hard by Stephan Schmidt

July 20, 2008

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.

About the author: Stephan Schmidt is currently a team manager at ImmobilienScout24 in Berlin. Stephan has been working as a head of development and CTO. He has used a lot of different technologies in the last 20 years including Java, Rails and Python. Stephans main field of interest is maintainablity and productivity in software development. Want to know more? All views are only his own.

If you did like this article but you don't want to subscribe to new articles with your reader, you can follow me on Twitter or subscribe to new posts with your email:

Comments

anjan bacchu

hi Stephan,

thanks for the info.

E-Tag : I’ve been reading up on this for a while. Would you know of a tutorial /introduction on how to use it efficiently ?

Thank you,

BR,
~A

July 21st, 2008
stephan

Sorry, I don’t have a tutorial at hand, everytime I implement something new wit etags I use google to find the information I need. It’s usually not very often.

Peace
-stephan

July 21st, 2008
Greg Wilkins

Stephan,

What versions of jetty/glassfish were compared? Also, any chance you can make the source for this project available, or at least something similar.

The difference between jetty/glassfish may be something as simple as default configured depth of accept queues. Unscientific as it is, its no fun having psuedo benchmarks published that you can’t analyse or respond to.

cheers

July 21st, 2008
lumpynose

With Rails it was 320 requests per seconds with what, 25 servers? Given my experience probably a significant percentage of those servers were needed because so many are being restarted by some external monitoring process because the Mongrel, Webrick, or whatever, was hung. One of the Rails fanboys here was complaining that the monitoring program he uses, god, was sending him several false positives emails a day about the server being hung. Talk about adding insult to injury. But he doesn’t see it that way or what black comedy the whole Rails thing is.

July 21st, 2008
stephan

What I miss when people talk about scalability, is not if somethings scales or not (your app should be designed in a way that it scales), but how much it will cost. Linear scalability for academics is the same independent of the scaling factor (2n or 10n), for business it makes a huge difference (5x more money though both technologies scale linear).

I think it’s funny that VCs don’t care about how much a chosen technology costs to scale.

And no, I have no facts that Rails doesn’t scale as good as e.g. Spring, just a gut feeling.

But the post was mainly to reassure me that my scaling factor for the REST solution is cheap, not to bash Rails/Ruby (I was afraid after reading the report).

July 21st, 2008
lumpynose

Very true.

I think the Rails scalability issue bothers me because I work with people who are Rails fanatics and their fanaticism blinds them to the scalability and reliability issues with Rails. The Rails people are typically chanting about how with it you can crank out a web app in no time at all, and within the Rails community you find very few people who think about the design and architecture of web applications. The whole mind set is to just use the tools that Rails gives you and be thankful that you don’t have to think about the gritty under the hood implementation details or alternative choices. They think of that as time wasted. I call it the Duncan Hines mind set. Duncan Hines is a cake mix in a box here in the states.

July 21st, 2008
stephan

@Greg: Sorry, no source code yet, but it’s a simple Jersey REST resource which returns Json.

The versions were probably not the newest, the Jetty plugin is 6.1.10, the Glassfish plugin is 1.0-alpha-4.

“The difference between jetty/glassfish may be something as simple as default configured depth of accept queues. Unscientific as it is, its no fun having psuedo benchmarks published that you can’t analyse or respond to.”

I’m sorry, with some hindsight I wasn’t clever to publish numbers, a “around 1000req/sec” would have been enough. As I’ve said, both are so fast, that the numbers are really no problem to me (but might be for others, I agree).

It probably wouldn’t help if I do another benchmark, with published source code and documented configuration.

That aside, 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.

July 21st, 2008

Leave a Reply