[mdlthree]

As an amateur hacker and after 275 days of reading Hacker News I feel I can now navigate in the sea of client side Javascript frameworks. With the introduction of this data on web framework performance, I now have another set of choices that I am completely unqualified to comprehend.

My first impression is that this data shows about 3 levels of web frameworks. At the bottom (slowest) we have Django's and Rails and many other introductory app server frameworks. Lets say after I was able to build an initial product successfully, would I then consider re-building the product in a higher performance framework as Go, Node, etc?

The third level, netty and gemini and servlet etc, I am not familiar with. Googling "netty" I get --"Netty is an asynchronous event-driven network application framework"-- I thought that is what Node is (in js) and Go does with gophers.

What are the use cases for these faster frameworks and do they follow an evolution of performance options that an app might go through?

[ConstantineXVI]

Most of these are bound to a language: choose a language first (and my answer to that question is "whichever one you're happiest working in and can get the job done"), then figure out which backend to use. You can fret over the framework more after you've already built something that works.

[cmsimike]

IMO if you build a product and it is working, there really is not much reason to redo your efforts in a higher performance framework unless your needs require you to do so. If you are at your current hardware's limits and you can't throw more hardware at it (for whatever reason), it may make sense in that case. If you want to reduce the amount of servers you currently have, it also makes sense there. http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2... This is a great post talking about going from 30 servers using Ruby to 2 servers using Go.

Use case example - Twitter was using Rails on the front-end for a while but it got to the point where using it made little sense. Part of Rails' performance is dependent on caching - which is really hard, if not impossible, to do well when you are dealing with live data.

FYI, Gemini is our framework that we've built and maintain internally. You probably won't find reference to it (except for out blog).

edit This is the link to Twitter's blog about Rails http://engineering.twitter.com/2011/04/twitter-search-is-now...

[trotsky]

The third level is java based frameworks that are making heavy use of highly optimized native code paths for string handling.

[avenger123]

All metrics are meaningless without context.

I like these comparisons. It's unlikely that anyone is going to pick a framework for their project based on just this alone.

I find its good "food for thought" as it provides me exposure to frameworks that perhaps I can use one day but also to learn more about.

The most interesting aspect is all the code for each framework to do the simple page output, the queries, etc. can be viewed for each framework. I find this an incredible learning tool as it shows the personality of each framework/language.

[pfalls]

"I like these comparisons. It's unlikely that anyone is going to pick a framework for their project based on just this alone."

This is exactly right, performance is one of many items to consider when building your own website, and while we're aiming to have a very comprehensive and useful set of performance data, we would agree that other factors need to be taken into account.

[Joeri]

Netty, gemini and servlet are all java server solutions without a thick framework layer getting in-between. What you can tell from these benchmarks in my opinion is that java (or rather the JVM) has the best "raw" performance. Frameworks introduce a slow-down factor on top of the raw platform, and different frameworks have different slow-down factors.

You have to trade off developer productivity for performance when it comes to choosing frameworks. The slower the framework the more it does for you.

[cgh]

EDIT: this appears to be a different "Gemini" than the one I'm talking about here - in a comment below, it's mentioned that the tested Gemini is built and maintained internally. So the next paragraph is probably irrelevant.

Note that Gemini is an OSGi framework built on top of Spring DM. For those who don't know, OSGi is Java modularity "done right" - basically a very loosely-coupled module system (which Java lacks) on steroids.

[cmsimike]

Gemini is a full-featured web framework. We've built it and maintain it internally. It offers caching (though not enabled for these tests), lightweight ORM, bunch of default handling methods and plenty of other features.

[kolev]

So you did all this to tell us indirectly that you have the best web framework in existence? ;)

[ebiester]

I keep thinking this is a pre-advertisement for the future release of Gemini... :)

[ineedtosleep]

In general, I echo ConstantineXVI's comment. However, I'm also curious to know where the definite line is between the bottom half and the top 5 on the table. At what point does a team go "We're getting hammered and our backend is the problem. We have to switch to X or Y because our API on Z has reached its limit."

[jcoby]

You will know when it becomes a problem. The helpdesk gets flooded. Servers go down. You get white pages and 500 internal server error pages. The entire site folds because a mouse farts.

You add new servers and they get crushed. You scrutinize every line of code and fix algorithms and cache whatever is possible and you still can't keep up. You look at your full stack configuration and tune settings. You are afraid of growth because it will bring the site down. THEN you know it's time to consider switching frameworks. And even then I would try to find the core of the problem and rewrite that one piece.

Rewriting an app in a new framework can kill a company. Be leery of starting over. I personally know of one company who started over some 4+ years ago because the old app was too hard to maintain and only started rolling out the new app last year to extremely poor reception (even with about 1/2 the features of the old app). The reception was so bad that they had to stop rolling it out until it was fixed. They could have easily spent a year improving the old app and would be miles ahead.

That's not to say that all problems are due to the framework either. I've had web servers go unresponsive for 20+ minutes because apache went into the swap of death because KeepAlive was set to 15s and MaxClients was set to a value that would exceed available RAM. The quickest solution was to cycle the box. This was 10 years ago though and I think I had a total of 1GB of ram to work with.

[reasonable]

This is exactly the sort of question that should be asked in the context of benchmarks like this. There have been a lot of good comments in response, but I just wanted to thank you for asking one of the best questions in this thread.

[doktrin]

I think it's a misconception to think of Django and Rails as "introductory frameworks". These are production ready frameworks that can scale to meet a variety of (though not all) business needs.

[mdlthree]

My intention of the word introductory was not to feel like training wheels. Joeri in this thread says:

>>You have to trade off developer productivity for performance when it comes to choosing frameworks. The slower the framework the more it does for you.

And in that respect, the more the framework does for a developer, the better it is probably suited a starting point for new developers. It is a badge of success that Django and Rails can be able to serve a whole spectrum of needs.

[doktrin]

Understandable, but I would offer a counterpoint.

When it comes to "learning" frameworks, I don't think the highest level of abstraction is necessarily the best. Some are better able to cope with black-box behavior than others. For those who feel the need to understand their tools as they use them, I'm of the view that the Sinatras of the world are a better starting point.