Can't believe you didn't include Zend in there :(
Web Framework Benchmarks
91–100 of 415 posts
Re: Web Framework Benchmarks
#92Earlier quoted context omitted.
I'd love to see your framework optimization index. Honestly, all of this would be a wonderful thing to automate and put in a web app - a readily-accessible, up-to-date measure of the current performance of the state of the art in languages and frameworks. I bet it would really change some of the technology choices made.
Here's a quick version of the framework optimization index. Higher is better (ratio of framework performance to raw platform performance, multiplied by 100 for scale): Framework Framework Index Gemini 87.88 Vert.x 76.29 Express 68.85 Sinatra-Ruby 67.88 WebGo 51.08 Compojure 45.69 Rails-Ruby 31.75 Wicket 29.33 Rails-Jruby 20.09 Play 18.02 Sinatra-Jruby 15.96 Tapestry 13.57 Spring 13.48 Grails 7.11 Cake 1.17
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 interpreted as too much editorializing. Nevertheless, as you point out, it's interesting to know how using a framework impacts your performance versus the underlying platform.
I too wanted Play to show higher numbers. There's certainly a possibility we have something configured incorrectly, so we'd love to get feedback from a Play expert.
Re: Web Framework Benchmarks
#93These are some brutal results for CakePHP (which I use). However, in practice no intermediate developer would be issuing queries like that in a loop. They would loop through a set of data, building a IN statement example: WHERE field IN ('x','y','z'). Thus only sending a single query to the database. Still, the Cake developers really need to improve the speed of their framework.
Re: Web Framework Benchmarks
#94So this means I should stop using CakePHP?
If you're serving only json snippets from memory and might have hundreds of simultaneous users, yes!
If you have existing sites built with it which work fine, then this benchmark doesn't tell you a great deal other than that php is relatively slow, and frameworks built upon it slower. For many websites which have a caching strategy sitting behind a server like apache or nginx and less than a few thousand users a day, this really doesn't matter, and other things like features are more important. This hlds even for bigger site too - Facebook for example still runs PHP (compiled to one big binary). Personally I wouldn't use PHP because of the language/std lib but this sort of performance shoot-out should not put you off it.
Re: Web Framework Benchmarks
#95There is a huge difference between raw PHP and CakePHP. I'd be curious to see other PHP frameworks (such as Zend, or Slim) in there-- is Cake just particularly slow, or is that simply what happens when you have a PHP framework?
I'm curious if they configured php with apc or zend optimizer. The huge difference is easy to explain as parse overhead for the framework's code, which happens on each request if you're not using a bytecode cache.
The relation of PHP to everything else in this benchmark is so unusual among benchmarks, that I strongly suspect a failure of parity with other configurations. Hopefully that is unintentional.
Re: Web Framework Benchmarks
#96Numerous 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.
Re: Web Framework Benchmarks
#97If you're going to include evented web libs like Node.js and the frameworks created using it, wouldn't it be fair to include other evented libraries such as EventMachine and Twisted?
Re: Web Framework Benchmarks
#98Probably not a major factor but I'm curious to know why mongoose was thrown into the mix for the node.js test rather than going with the native mongo driver. It might be more of a real world test to include mongoose with the node+express test, but for the node-only test the native driver might be more appropriate.
We wanted to use an ORM in all cases, it was only recently that we started working on native mysql access. We hope to add native mongodb results as well.
Re: Web Framework Benchmarks
#99Numerous 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.
Could you elaborate? Their website seems to indicate that they are a very polyglot shop, not someone pushing a JVM agenda:
"On the back-end, we use Java, Ruby, Python, .NET, PHP and others based on what makes sense balancing server performance, scalability, hosting costs, development efficiency, and your internal development team's capabilities."
Re: Web Framework Benchmarks
#100Very interesting! But isn't there a disavantage for node.js considering it's single threaded? Did you cluster it to use every core on the box ? ( http://stackoverflow.com/a/8685968/1909827 - "Scaling throughput on a webservice")
From the OP's response to a similar question:
>We attempted to take advantage of threading/multiple-processes as best we could (see the nodejs code for an example of using the cluster module). But we suspect there are additional areas of improvement here.