Taking a little break in my work today, I did some reading about yet another MVC framework that has exceptional performance yada yada yada. That framework is DooPHP. I'm pretty impressed with the performance actually though this is based on what they stated on their site. I couldn't get it to run on my system!
This prompted me to test against my idea of how an MVC approach should work. I ran apache bench (AB) against a fresh install of Codeignitor 1.7 as well as a local copy of Turbine Dump. I was only slightly surprised to find that the The Dump was a bit slower, but then it's connecting to a DB, performing sessions checking, and all kinds of other mumbo jumbo a completely written and functioning application would.
That said, I copied the app to a different directory and disabled all the bells and whistles. I was still doing all the needed includes, but instantiating nothing other then the base Pavelow factory class as well as the sessions class. Just enough (I felt) to have the Dump kick out a ye ole familiar "Hello World" line.
Benchmark time! I ran ab against each framework for 1000 request and a concurrency level of 5.
Now the good news is that the Harvested Framework I use (that i've been calling Leonidas) had an average test result of 4.20 seconds. Cool! 1000 returns from the site in 4.2 seconds? Yeah, I was feeling good.
Codeignitor (CI) turned out the same test with an average result of 8.58 seconds. Now this really isn't that bad when you consider two things.
1) Turbine Dump / Leonidas is actually a procedural MVC approach that relies on a OO Framework I wrote called Pavelow for it's DB, pagination, and error logging processes. CI OTOH is fully OO. That means a good deal of difference in instantiation overhead alone.
2) CI is about the best performing MVC framework out there with the exception of DooPHP (which or course prompted all of this). Others such as Symfony and Cake are positively behemoths. If you remeber or know what RISC and CISC stand for, Cake and Symfony are clearly CISC frameworks.
Anyway, I decided to start reloading and turning things back on to see how these affected performance. Here goes....
1) Just including Pavelow increased the average of the same test to 7.18 seconds! That's significant overhead for simply loading and parsing the files.
2) Including and instantiating the Pavelow Factory brought the test results up to 7.41 seconds.
2) Now it starts to get ugly! Adding the DB Sessions class alone (but no instantiation) shot the average test result up to 12.65 seconds!!!!! This doesn't even include instantiation. Just parsing overhead! Thankfully, instantiation overhead only resulted in additional 1 second (13.86 to be exact). And thankfully yet again, an op-code cache is going to kill this kind of performance penalty.
To put a point on how significant the penalty of the DB Sessions class is, my inclusion of it is essentially my including just one file. OTOH, when including the Pavelow core, it also includes 7 other classes! That said, the up front penalty of parsing all 8 classes is still far below that of DB Sessions. It really does look like I'm going to have to write a db sessions component into Pavelow.
But all of the above said, I can now see that if I ever formalize Leonidas into a package fit for distribution, it'll stomp the OO frameworks in terms of performance.
Showing posts with label PHP. Show all posts
Showing posts with label PHP. Show all posts
Saturday, October 31, 2009
Wednesday, September 10, 2008
So I'm not crazy after all
This about says it all!
And BTW, if you're not a geek or PHP guy, feel free to ignore this post. As a matter of fact, you may be happier if you do.
And BTW, if you're not a geek or PHP guy, feel free to ignore this post. As a matter of fact, you may be happier if you do.
Labels:
Drupalcon,
PHP,
Rasmus Lerdorf,
scalability,
slow frameworks
Thursday, April 17, 2008
Console_GetOpt
For you PHP nerds out there, I'm sick and tired of GetOpt. It's nice and useful for dealing with gathering command line arguments, but HOW you get to those arguments is the problem.
As an example, if I pass an argument to a script such as ....
"some_script -p Jack -u Dempsy"
... then the data structure I get back is something like...
Now is it just me or is that kind of cumbersome? Wouldn't it be nice to get back something like...
That said, I wrote this.
This will provide the type of data structure we're talking about.
I sent this as a note to "somebody" at the PEAR site. It would be great if I could actualy send it straight to a maintainer but the site doesn't seem to support this.
Now let's see what happens shall we?
As an example, if I pass an argument to a script such as ....
"some_script -p Jack -u Dempsy"
... then the data structure I get back is something like...
Array
(
[0] => Array
(
[0] => Array
(
[0] => p
[1] => Jack
)
[1] => Array
(
[0] => u
[1] => Dempsy
)
)
[1] => Array
(
)
)
Now is it just me or is that kind of cumbersome? Wouldn't it be nice to get back something like...
Array
(
[p] => Jack
[u] => Dempsy
)
That said, I wrote this.
function &condense_arguments($args)
{
$new_args_list=array();
foreach($args[0] as $arg)
{ $new_args_list[$arg[0]]=$arg[1]; }
return $new_args_list;
}
This will provide the type of data structure we're talking about.
I sent this as a note to "somebody" at the PEAR site. It would be great if I could actualy send it straight to a maintainer but the site doesn't seem to support this.
Now let's see what happens shall we?
Subscribe to:
Posts (Atom)