It just goes to show that your framework of choice is pretty unimportant. The developers (and their skills), who are actually developing on and configuring the framework, outweigh the "baseline" for performance on multiple orders of magnitude. From that I'd say that developer friendliness (easily approachable concepts) and sensible defaults is by far the most important thing when choosing a framework.
Web Framework Benchmarks
401–410 of 415 posts
Re: Web Framework Benchmarks
#402You're using PDO in the PHP raw test - use direct mysqli_* API, it's lot faster than the PDO abstraction layer.
Re: Web Framework Benchmarks
#403I haven't looked at this detail yet, but it should be noted that we haven't even optimised Vert.x yet so there should be plenty of scope for further improvement :)
(Disclaimer: I'm the Vert.x project lead)
Re: Web Framework Benchmarks
#404Earlier quoted context omitted.
>You and tikhonj are all over the place in here I am all over the place in here for the exact reason I mentioned. Go look at my posts, for every post about haskell by me, it is in response to someone posting some absurd nonsense like "haskell can't do real world" and "functional programming is great except you can't really do it because state". If people were interested in haskell, they would express interest, not st…
But that is like claiming nobody wants gay marriage because look how loud those Westboro people are screaming. I'm interested in Haskell. I find it to be frustrating sometimes, and sometimes I vent my frustrations. It is hard to learn. But out of all the opinionated languages out there, Haskell is the one that I agree with the most. There plenty of people here that are obviously interested. Why does it matter that th…
>But that is like claiming nobody wants gay marriage because look how loud those Westboro people are screaming.
That analogy would only be accurate if those Westboro people were in the majority.
>Why does it matter that the naysayers say nay?
I'm not sure how to answer this, given the context. I simply pointed out that I don't think the idea that there's a lot of interest in haskell here is accurate, and cited all the uninformed crap spewed about haskell all the time as evidence.
Re: Web Framework Benchmarks
#405Earlier quoted context omitted.
That's because they inexplicably use the Jackson library for the simple test, rather than Play's built in JSON support (they use the built-in JSON for the other benchmarks).
Both Netty and Play use Jackson though one the Netty version uses a single ObjectMapper and the Play version uses a new ObjectNode per request (created through Play's Json library).
I hope this gets fixed!
Re: Web Framework Benchmarks
#406Hi, great work! I only have two suggestions:
a) Please, publish not only the requests per second, but the memory and CPU usage of the machine for each framework. b) For JAVA systems, can you publish de heap configuration of the JVM?
Cheers!
Re: Web Framework Benchmarks
#407Earlier quoted context omitted.
It's funny you should put this together because in an earlier draft of this blog entry I had created a tongue-in-cheek unit to express the average cost per additional line of code. Based on our Cake PHP numbers, I wanted to describe PHP as having the highest average cost per line of code. But we dropped this because I felt it ultimately wasn't fair to say that based on the limited data we had and it could be easily i…
Good thing you opted against sensational journalism. About the cost per additional line of code for PHP, it mainly comes from not having an opcode cache and having to load and interpret files on every visit. mod_php was and will always be trash. I commented earlier about it too. In case of Ruby, and talking about Rails, even when using Passenger, the rails app is cached via a spawn server. That's not the case with PH…
I am completely agree with you, this is not proper bench marking as opcode caching is missing in php, benchmarking should be re calculated by configuring APC.
Re: Web Framework Benchmarks
#408Earlier quoted context omitted.
Erlang would be nice to see, with, say, Chicago Boss.
Agreed. As you can imagine, we had to stop adding additional frameworks somewhere or we'd never get this posted. :)
I've send a pull request for the cowboy webserver (erlang based) it does pretty well in my local tests :) ranks between Go and gemini
Re: Web Framework Benchmarks
#409Regarding PHP, well, isnt CakePHP by far the slowest major PHP framework? Why dont you test the other PHP frameworks? How about Yii, Codeigniter, Lithium and Symfony? Id say the result is kinda biased for PHP frameworks since you pick the slowest PHP framework available, instead of the fastest or at least the average one.
Re: Web Framework Benchmarks
#410Also I dont think evaluating json based on a simple 'Hello World' is a valid test. In fact, 'hello world' should never be the standard to test the speed of any processes. If all your script does is to output 'hello world' to the screen, why bother using a server-side programming language at all? You are better off just writing it in HTML, its faster than using any server-side and client-side languages lol.