Why these frameworks so slow?

[Stopofeger]

Hi there,

after reading the manual and coding a bit on both cakephp and codeIgniter.

I can surely say cakephp is definetly what a "Rapid Development Framework" shud be. So I thought I would use it. There is a lot of apps building in cake so i downloaded some and installed bakesale, a shopping cart. But its extremely slow. it takes 6-7 seconds to fully load it. So i looked at my cakephp hello world app. It takes 2.5 seconds? Why so slow?

I tried ab benchmarking tool on both oscommerce and bakesale and cakehello. Both of them donbt stand a chance against oscommerce.

I tried searching and found a benchmark with the most least coding possible.

http://paul-m-jones.com/blog/?p=238

Just look at it. How come in 2700page/s server just serves 114 pages for cakephp and even 53p/s for symfony. The fastest is solar with not more then 170.

If this goes, how we gonna use them? It will make things unbelivably slow.

And they didn't mention CI as an MVC framework. And it is actually not the answer.

[Ninjakreborn]

The "rapid development framework" doesn't mean the system itself run's rapidly (though it should).  It means it's meant to help you developer site's and web applications more "rapidly".

[redbullmarky]

i'm not dismissing the results, but I've noticed a vast difference getting a large, properly structured site ticking along nicely compared to doing 'hello world' and <? for ($i = 0; $i < 100000000; $i++) type tests.

By their nature (ie, being a framework with lots of bells and whistles), I've found CMS's like Drupal, etc, much slower still - however, there are plenty of tried and tested examples (some huge sites) that chug along quite happily on these, with no REAL noticable difference to the user.

 

What you'll find though is that many of these frameworks are also "one size fits all" type things, designed to be useful to any coder. If you get to know the Cake or CI source well enough, you'll soon realise that there's stuff that's included in the core that never gets used and can be removed. Also, like he states, the use of proper caching can bypass all of this bulk anyway.

 

I personally based my own framework on Cake/CI, based on what I liked and didnt like. It does exactly the same as both of them, has all the bells and whistles I need (or will probably ever need) yet is only a fraction of the size.

 

I am a believer that if you want to use a framework, you really should know what it's doing and get under the bonnet properly. Once you've done this, you should find it easy enough to remove some of the unnecessary bulk that you dont need.

 

Take the results on board, be aware of what might be causing the issues, etc - but be aware also that there are thousands of high traffic, popular sites out there built on some of these frameworks and CMS's without issue.

[Stopofeger]

Although i haven't seen CI api but I have looked through cake. And I must say it uses REGEx too much. the inflector have about hundred patterns. RegEx are much slower then str functions.

And their requestAction() function probably is the main suspect of slowness as it's like running multiple page request.

BTW, red can u tell what exactly takes all the cputime? in cakephp and how can i bypass this?

Because the current speed impossible for production use. Caching is not alway the answer in dynamic pages.

[redbullmarky]

i'm not totally sure. i can't remember whether it's cake or CI that has a benchmark which logs the time at each intersection. failing that, if you really wanna find out, you'll need to be looking at the dispatcher (dispatcher.php) as it's that file that's responsible for handling the initial request, firing up the controller (including loading its dependencies/models, etc) and handling the final view.

 

there's an article listed under 'resources' at the top of the app design forum that looks closely at the dispatcher if you get stuck.

[Stopofeger]

well its in CI, Yes looked in to the dispatcher. It didn't looked to have much problem. But i really have this feeling about requestAction(), it even returns rendererd output, that means we need to dispatch it again.

 

Btw, is there any way to use a controller within another controller but not with request action?

we can use models with $uses var. what about other components?

[redbullmarky]

again, i'm not sure, but i believe from a cake point of view, controllers within controllers are referred to as components. i use the equivalent's in my own framework to handle things like blogs, articles, message boards, etc so i can keep the main controllers a bit more manageable and more app-specific

[Stopofeger]

Ok after doing some profiling myself in the dispatcher and the requestAction definition i got the answer.

requestAction() function runs the dispatcher again restarting the entire process of controller initialization, rendering and uses ob_* functions to get the output.

So its like requesting the page  multiple times.

 

bakesale uses requestAction too much making it really slow.

 

So a suggestion to all, Don't use requestAction until there is no alternative at all. Keep ur generic methods in the models.

 

[redbullmarky]

hmm unless i'm looking in a different way, i cant see where/why the dispatcher gets run again, unless it's for stuff like scaffolding or error pages. can you share the details?

[Stopofeger]

well i dont remember the full source code of requestAction() but the psedo code is something like this:

requestAction($url,$options)
{
if($option["return"])
{
//return the output flag
}
$disp=new Dispatcher(args)
ob_start()
$disp->dispatch($url)
$output=ob_get_clean()
}

 

this is almost like that. u can check the source urself.