171–180 of 415 posts
"Among the many factors to consider when choosing a web development framework, raw performance is easy to objectively measure." Oh really? Then why did Zed write such an angry rant about how you are doing it wrong? http://zedshaw.com/essays/programmer_stats.html Can we please see some standard deviations, at least?
I'm curious to see Django results when using the gevent worker for gunicorn. For these type of quick JSON calls, you can see huge performance increases.
What kind of server did you guys use for your rails test? Thin, Puma, Unicorn? Are you sure you ran it in production environment? Update: Looks like passenger in development mode. Good job you benchmarked a web server that no one uses wile reloading all code between requests. Update2: Ok it seems to run in production mode but still, passenger is not an idiomatic choice.
Earlier quoted context omitted.
Just had a look at the tests and the urls responded to differ: http://localhost:8080/json http://localhost:8080/ (.*) Shouldn't all these examples at least be trying to do the same sort of work? For such a trivial test differences like that could make a huge difference to the outcome. It's great to see replicable tests like this which show their working, but they do need to be testing the same thing. I also think the…
One of the next steps we'd like to take is to have a test that does cover a more typical web request, and is less database heavy than our 20 query test, just like you describe. Ultimately, we felt that these tests were a sufficient starting point.
I can't think of much else that this little web.go framework does (assuming the fcgi bits etc are unused now and it has moved over to net/http). I don't think many people use web.go, gorilla and its mux router seems to be more popular as a bare bones option on Go, so it'd possibly be interesting to use that instead. It'd be great to see a follow up post with a few changes to the tests to take in the criticisms or answer questions.
While you may come in for a lot of criticism and nitpicking here for flaws (real or imagined) in the methodology, I do think this is a valuable exercise if you try to make it as consistent and repeatable as possible - if nothing else it'd be a good reference for other framework authors to test against.
Earlier quoted context omitted.
A good tip build tends to be more stable then 1.0.3 and has hugely improved performance (most importantly for large application in garbage collection and generation). To select a suitable tip build we use http://build.golang.org/ and https://groups.google.com/forum/?fromgroups#!forum/golang-de... . My recommendation would be to find a one or two week old build that passed all checks, do a quick skim of the mailing li…
Thanks, this comment really helped me in my evaluation of Go today. I had been playing around with 1.0.3 for a couple days, but tip is definitely where it's at.
There 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.
And if this is the case with their configuration of PHP, it makes me wonder what other platforms are not configured for production in this benchmark :)
"Among the many factors to consider when choosing a web development framework, raw performance is easy to objectively measure." Oh really? Then why did Zed write such an angry rant about how you are doing it wrong? http://zedshaw.com/essays/programmer_stats.html Can we please see some standard deviations, at least?
Earlier quoted context omitted.
Not really. Take this benchmark with a grain of salt unless they benchmark it again with APC at minimum. Nobody serious about a web app would run a PHP app without APC. Similarly, relatively modern deployment standards (not really cutting-edge) like nginx and php-fpm OR apache 2.4 with worker mpm + php-fpm should be added to the mix.
Asadkn, we'll try to get things revised based on your feedback. Admittedly, we have some learning to do with tuning production PHP environments.
apc.enable=1 turns on Opcode caching (when php-apc is installed), and apc.stat=0 turns off "stat" checks - this means that once a file is opcode cached, PHP won't even have to touch the file on disk to execute it. The I/O gains from this, as well as the execution gains from not having to parse the file, should help quite a bit.