So this means I should stop using CakePHP?
So this means I should stop using CakePHP I always strongly advise not using CakePHP, purely because its model system is so broken, it makes my teeth itch.
How is it broken?
Web Framework Benchmarks
131–140 of 415 posts
Re: Web Framework Benchmarks
#132What would be much more interesting than "peak responses per second," which is a weird metric to begin with, is the actual histogram of sampled throughputs. Or at the very least a box-and-whisker plot (http://en.wikipedia.org/wiki/Box_plot).
Most folks who have run Rails at scale, for example, find that the untuned garbage collector in MRI (Ruby's default interpreter) introduces a large amount of variance, for example.
Re: Web Framework Benchmarks
#133Earlier quoted context omitted.
[deleted]
No, they're not. They can run via CGI (so, yes, compiled for each request) but that's slow as ass. They run via Plack/PSGI - they can be deployed in a multitude of ways, including via FastCGI or running standalone using built-in webservers, or via Starman - the latter in particular is very fast indeed. With a simple "hello world" type app, > 6000 requests/sec can be easily handled. Obviously an app of more realistic…
Funny enough that SO link was the same one I got my misinformation from as the top answer pointed to CGI benchmarks.
Thanks for the correction though, but that still doesn't answer my original question: how does Plack compare with mod_perl?
Re: Web Framework Benchmarks
#134I'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.
Re: Web Framework Benchmarks
#135What 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.
Re: Web Framework Benchmarks
#136What I've also found is that Node (V8) tends to have much higher variance in response times when compared to Java Servlets (JVM): https://github.com/olegp/common-node#benchmarks
Re: Web Framework Benchmarks
#137This is exactly why I decided to use PHP for my startup. I have something along these lines that I hope to blog about in the coming weeks (I tested php-fpm on nginx/go/node.js/silk.js and php won by a landslide when it came to speed).
I would love to see php-fpm on nginx included in this test.
Re: Web Framework Benchmarks
#138Earlier quoted context omitted.
Webgo... I'll stick with "net/http" and Gorilla thanks. Also, They used Go 1.0.3... I hope they update to 1.1 next month. Most everyone using Go for intensive production uses is using Go tip (which is the branch due to become 1.1 RC next month)
Wow, directly on tip? That seems to speak very highly of the day-to-day development stability of Go.
Or it could speak poorly of their release process, which is more accurate. The stable release is simply so bad compared to tip that everyone uses tip. There should have been multiple releases since the last stable release so that people could get those improvements without having to run tip.
Re: Web Framework Benchmarks
#139Earlier quoted context omitted.
So this means I should stop using CakePHP I always strongly advise not using CakePHP, purely because its model system is so broken, it makes my teeth itch.
How is it broken?
How is it broken?
All data is returned as an associative array, so there is no way to call something like:
$cows = $this->Cows->findByStatus(COW_STATUS_NOT_MOOING);
foreach($cows as $cow)
{
$cow->moo();
}
The big issue is: all data is returned as an associate array! There is no lazy-loading of the data as you e.g. seek through it, which means it's very easy for people to pass around huge arrays with thousands upon thousands of rows and associations without even thinking about it.
/rant over
Re: Web Framework Benchmarks
#140What's the difference between "php" and "php-raw" in some of the data? Maybe I'm still in my morning fog, but having trouble thinking of what "php-raw" might mean. Sigh.
The code says php-raw refers to using PDO (which all project should be using) vs using an ORM or ActiveRecord. I am completely stunned by the performance cost of using ORM/AR, and will be using this to shame our team lead into giving it up and going for raw queries.
Some of the ORM cost can be mitigated by using caching. In most cases this is essential in a production deployment.