My two cents: If your primary goal is to have a FAST webpage serving images and multimedia content, you build static HTML with maybe some PHP using lighttpd.
If you are building a social network/heavy interaction app (think friendfeed/facebook) you either build the framework yourself or spend equally lots of time tweaking a framweork like cake or zend. Or do it like google, where the google.com frontend/search dispatchers are in low-level C++. I think Cake is a fast, stable and mature framework compared to a lot of the other offerings. However, the main reason for most people for chosing cake is fast coding and deployment. Many of the cake apps are business applications where modeling of business logic, forms and views is important, and thus the speed of doing this is much more important than the 0.2 or 0.6 processing time of the finished app. (This is guessing, but I belive many cake apps are internal business apps of which few are shown to the public or on the "who's using cake" page on cakephp.org). For most people making such apps the speed of the dispatcher, template engine etc is unimportant. The parts slowing the app would be heavy SQL, SOAP/XML-RPC-request to other apps or huge batch ETLs. For most people (including most public websites) the most important thing would be faster SQL/active records and a better implementation of HABTM joins, not the ability to serve x or y pages per sec. //mathias 2009/1/2 nurvzy <nur...@gmail.com>: > > Cake has a lot of things going for it, and I mean A LOT that the other > PHP frameworks don't have. However, I disagree that performance > doesn't matter much. A lot of us (especially in this economy) are > downsizing our servers which is one of the main reason to even look at > a PHP frameworks over something like Rails. Setting up a Mongrel > cloud and the CPU/Memory to back it up on a host can be an expensive > proposition whereas PHP interacts with Apache directly and PHP in > general is widely supported among all hosting companies. Coming from > a Ruby on Rails background, this was my main draw to developing in the > CakePHP framework; speed and savings due to decreased need for > hardware plus added benefits of not having to re-learn techniques I've > learned from years of ROR developing. > > Don't get me wrong, I'm very impressed with the speed of CakePHP and > the framework itself, but it is a little scary to see the performance > nearly cut in half going from 1.1 to 1.2 in each of those performance > tests. I hope this will not be a trend with every release. > On Jan 2, 7:43 am, Mathew <nfoscar...@yahoo.com> wrote: > >> Also, with the cost of hardware dropping everyday. A framework >> designed purely for performance will become outdated as other more >> complex "slower" frameworks offer better features and return on >> development costs. >> >> A well designed framework no matter how slow its internals can be >> improved without affecting the functionality of the application the >> framework is driving. Something that the Cake team can address with >> maintenance releases to address performance. >> >> With all that said, I do believe Cake is one of the slower frameworks. >> The extensive use of for/loops during dispatching and rendering of >> views has to impact performance, but the level of performance impacted >> depends on the implementation of the website. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
