361–370 of 415 posts
Numerous irregularities plus a strong vested interest in the JVM make me doubt they have given adequate shrift to Go, here. Given the amount of interest in Haskell and Yesod around here, it is strange that it is missing.
Would love to see how these results compare to some of the web frameworks for concurrent functional languages like Erlang/Haskell: Nitrogen, Chicago Boss, Snap, Yesod, etc.
Would love to see how these results compare to some of the web frameworks for concurrent functional languages like Erlang/Haskell: Nitrogen, Chicago Boss, Snap, Yesod, etc.
> This exercise aims to provide a "baseline" for performance across the variety of frameworks. By baseline we mean the starting point, from which any real-world application's performance can only get worse. I disagree with the implication here (that this is a good point for comparison because "real-world application's performance can only get worse."). Yes it can only get worse but how much worse (per unit of "featur…
We know that there is a set of common features and the benchmarks goal is to test least common denominator stuff on the networks. Authentication and portability are not LCD. The argument that they are is capricious. What if we made the requirement be that the framework is a lisp? Now we've completely changed the intent.
And to on top of this compare database requests is meaningless as the blocking nature of the framework itself is the major bottleneck, and not the database.
Now, for a normal web application, the largest amount of request would come from static content, or cached content within the web app so the real gain would be a tiny fraction between python/ruby and go/java-based frameworks.
That said, if you want to handle static content (images and such) from within your app, or build a java script-centric application with lots of tiny requests, or even persistent once...nor rails or django would do.
Earlier quoted context omitted.
If you have developers who for one reason or another prefer a given platform, then the most important performance comparisons are about how close various frameworks on that platform get to the performance of the platform itself. Knowing how much I'm giving up in performance in order to get the features a given framework gives me is an important consideration. Also understanding when it's worthwhile to work outside th…
How do you derive how much performance you are giving up from these benchmarks? There is not a neat relationship between the two.
See my "framework optimization index" in comments below for a rundown on all these ratios which I was able to back out from this set of benchmarks.
Earlier quoted context omitted.
These could probably be further broken down into micro-frameworks (like Express, Sinatra, Vert.x etc.) and large MVC frameworks (like Play and Rails). Gemini is sort of an outlier that doesn't really fit either category well, but the micro-frameworks have a fairly consistently higher framework optimization index than the large MVC frameworks which is as expected. Express and Sinatra really stand out as widely-used, v…
I'd imagine that being relatively young is an advantage in a test like this. You're not utilizing any features, and features are what slow down requests. The less features something has, the faster it should perform in these trivial tests.
I still believe launching a usable web application next week is preferable to launching a really fast web application 3 months from now, if ever.
That's a straw man. Competent programmers should be able to code fast code in a fast manner.
Earlier quoted context omitted.
In the same vein, I was curious to compare the max responses/second on dedicated hardware vs ec2 on a per framework basis. The following is percentage throughput of ec2 vs dedicated (in res/s): cake 18.9% (312 vs 59) compojure 12.1% (108588 vs 13135) django 16.8% (6879 vs 1156) express 16.9% (42867 vs 7258) gemini 12.5% (202727 vs 25264) go 13.3% (100948 vs 13472) grails 7.1% (28995 vs 2045) netty 18% (203970 vs 3671…
You're saying that running a query across the internet to ec2 is 5 times faster than running it on dedicated hardware in the lab? I find that hard to believe.
So, in responses per second, the throughput on ec2 was 5.2% that of dedicated hardware, or approximately 20 times less throughput. The use of the word slowdown was possibly a bad choice, as none of my response had to do with the actual latency or roundtrip time of any request.