Why would you? If you write clean maintainable code and are productive using it there's no problem, there are tons of ways of tuning Cake (as most frameworks). The default configuration is meant for 'bootstrapping'.
However, if you are interested, you can always check out other PHP frameworks (Yii, slim), or if you like all the bell and whistles from Cake and are willing to dive into another language, you can always experiment with ruby (ror, sinatra), node (express) and python (flask).
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.
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.
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.
Obviously, the data should not steer you towards rewriting applications using a different framework. Really, it should just show as another metric to help deciding which framework is best suited for your needs. If you plan on writing up a blog application for yourself and you might get 100 concurrent users, then you could use CakePHP for the sake of familiarity. Then again, if you are trying to write the next Twitter and have the requirement of needing to be able to service 20,000 concurrent requests, then I would say "yes, this means you should stop using CakePHP."
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();
}
But that's pretty minor.
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.
I don't use Cake, so don't read this is a defence of Cake.
Lazy loading seems to me a kludge trying to fix poor SQL querying. If you can filter at the app layer, why not pass the information down and filter at the DB layer? You'll be transferring less data and may even read less data from disk (with proper indexes)
Lazy loading seems to me a kludge trying to fix poor SQL querying.
I very much agree with you, lazy loading should not be used as substitute for only querying and/or filtering the data you actually need.
However, there's always going to be a minimum; eventually, the data needs to be processed or displayed! Why load all of it immediately into memory (and potentially pass that around), rather than when it's actually needed?
I think of it a bit like using pointers; passing around the location of the data, rather than the data itself, makes life good for all concerned.
I don't use Cake, so don't read this is a defence of Cake.
Thanks for the disclaimer, as I'm guessing you've experienced before, it's all too easy to get into accidental flamewars about this stuff :)
