101–110 of 241 posts
This is our first follow up to last week's web framework benchmarks. Since last week, we have received dozens of comments, thoughts, questions, criticisms, and most importantly pull requests. This post shows data collected from a second run on EC2 and i7 hardware that started on Tuesday of this week. A third round with even more community contribution is already underway. Thanks especially to those who have contribut…
Earlier quoted context omitted.
Pls could u include some C/C++ web frameworks... comparison with Java, could be interesting..
yes please! There's got to be a C++ framework out there to test. Casablanca?
Yesod disappoints! Unfortunate for how much it is hyped. This is definitely good to know, even if it appears that the Warp server was not used.
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 ma…
A note about Compojure: they're using Korma for database access. Korma is an abstraction layer that's more Clojure-friendly than using SQL directly, but lighter than an ORM. Using clojure.java.jdbc might produce higher performance.
It's a useful data point to know the speed of frameworks, but what matters most to me is speed of development and whether or not I enjoy the process. Wish there was a way to benchmark those points.
>what matters most to me is speed of development and whether or not I enjoy the process. Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important…
You can throw money at Rails and it will handle the load, but it would cost a lot more.
One of the variations that is being tested here, that I'm not sure if it is legitimate is that for PHP specifically, Apache is likely spinning out many PHP threads, I'm not sure if the same behavior is happening on the ruby side. Thus, if you are comparing performance of 10 PHP threads to 1 ruby or python thread, your benchmark is not going to be terribly accurate.
PHP was tested behind nginx this time due to community feedback we received, not Apache.
Is anyone else alarmed to see raw PHP spanking Flask, Sinatra, and other Python/Ruby frameworks? If not, can anyone explain in layman's terms why that should be the case?
Not sure about ruby, but django doesn't ship with connection pooling, so that is probably why its database performance is terrible. It could be configured to use pooling. With such a trivial request handler like the one in benchmark, only a small percentage of the execution is actually taken up in the view, so all of the time you're seeing in the benchmark is pure overhead of the framework. A longer running view acro…