EllisLab text mark
Advanced Search
     
CodeIgniter vs CakePHP benchmarks
Posted: 19 August 2010 07:03 PM
Avatar
Joined: 2010-08-18
24 posts

Just in case anyone is interested, I’ve just finished rewriting a website from CakePHP (1.3.2) into CodeIgniter (1.7.1).

As this is a client site, I can’t really release any of the code for it, suffice to say that both sites are accessing the same MySQL database - the same tables - using MySQLi driver, so its relatively safe to say that the framework is being tested.

The code accesses the database, loads the content of one page, then performs a series of other queries to select some content for menus and sidebars. In total CakePHP is performing 12 queries, and CodeIgniter 11.

CodeIgniter is using DataMapper DMZ for all of the model functionality, CakePHP is using its built in ORM.

Both sites have the bare minimum of libraries/helpers loaded for the functionality.

Both are testing using AB - “ab -n 1000 -c 10 etc etc” being the bare functions. If anyone wants it run again with other options I’d be happy to oblige.

So, if anyone is interested in the score then here we go:

CakePHP:

Concurrency Level:    5
Time taken for tests:  163.970 seconds
Complete requests:    1000
Failed requests:      3
  (Connect: 0, Receive: 0, Length: 3, Exceptions: 0
Write errors:        0
Total transferred:    5258574 bytes
HTML transferred:    4918596 bytes
Requests per second:  6.10 [#/sec] (mean)
Time per request:    819.851 [ms] (mean)
Time per request:    163.970 [ms] (mean, across a
Transfer rate:      31.32 [Kbytes/sec] received


CodeIgniter 1.7.1

Concurrency Level:    5
Time taken for tests:  11.004 seconds
Complete requests:    1000
Failed requests:      0
Write errors:        0
Total transferred:    5264678 bytes
HTML transferred:    4921926 bytes
Requests per second:  90.88 [#/sec] (mean)
Time per request:    55.020 [ms] (mean)
Time per request:    11.004 [ms] (mean, across all
Transfer rate:      128.06 [Kbytes/sec] received

Wow

To be honest, I think CakePHP is suffering a little on my local machine (performing this on a PC laptop rather than my normal Mac), but the difference is blinding. I would describe myself as an experienced CakePHP coder, and an inexperienced CodeIgniter coder, so I’d guess someone else could squeeze some more out of it.

That is a pretty comprehensive beating there, and I’m slightly at a loss as to why its so bad. Neither framework has caching enabled on those results, so there isn’t a false positive coming from the CodeIgniter there.

Got to say, I’m hugely impressed - and excited to see what CodeIgniter can do once there is some caching installed and running.

PS The spec on this laptop is AMD Athlon X2 QL65 2.1Ghz running 4gig of RAM on Windows Vista Ultimate with Wampserver 2.0 running PHP 5.3.0

 Signature 

Proudly making daft mistakes in PHP since 2002.

 
Posted: 20 August 2010 05:36 AM   [ # 1 ]   [ Rating: 0 ]
Avatar
Joined: 2009-03-10
1388 posts

Requests per second:  90.88 [#/sec] (mean)

This is actually quite slow. Especially for CodeIgniter standards. To get an indication of what is possible using CI take a look at this benchmarking site.

 Signature 

Isset | Isset Public Code Repo | Simple Message Library | Session Profiler for CI2.0 | CI session issues in IE

 
Posted: 20 August 2010 08:24 AM   [ # 2 ]   [ Rating: 0 ]
Avatar
Joined: 2010-08-18
24 posts

The whole point is that this is not a HelloWorld - its a fully functional, fully fledged site with database access, user login sessions, dynamic routing etc. There is little point being able to hit 2500# requests/sec if that bears no relation to what you actually need the program to do. I had seen the other thread, and the reason that posted a new thread is that it wasn’t relevant there.

Also, the thread you linked to was for serving a html page containing hello world, not getting CI to render it!

So really not what is possible using CI at all.

 Signature 

Proudly making daft mistakes in PHP since 2002.

 
Posted: 20 August 2010 10:58 AM   [ # 3 ]   [ Rating: 0 ]
Avatar
Joined: 2009-08-23
34 posts
J Maxwell - 20 August 2010 12:24 PM

The whole point is that this is not a HelloWorld - its a fully functional, fully fledged site with database access, user login sessions, dynamic routing etc. There is little point being able to hit 2500# requests/sec if that bears no relation to what you actually need the program to do.

I agree. Many people go on about how fast CI is, and yes, there is no disputing that, but no application is just going to be printing out nothing but unformatted “Hello, World!” all night and day is it?

But these figures are great. Good work on getting them. I also was a CakePHP developer but then made the switch to CodeIgniter and didn’t even need any benchmarks to see the difference. After the first couple of apps I wrote with Cake I can remember testing and using them and thinking, why are they so slow?!  With CI it was such a noticeable difference.

Suffice to say I stayed with CI and here I am now smile

 Signature 

“To the user, the interface is the system”

Fivetwelve - Web design, development & consultancy, based in Mid-Wales

Twitter - Follow me @512uk

ftw.gd - The l33t URL shortener from Fivetwelve

 
Posted: 23 August 2010 09:05 AM   [ # 4 ]   [ Rating: 0 ]
Avatar
Joined: 2010-08-18
24 posts

OK, if anyone cares, I’ve been further playing with my application in CodeIgniter. I’ve upgraded to CI 2.0, added Modular Separation, and some caching. This is a combination of using CI’s native output cache, coupled with eAccelerator and Zend Optimiser.

The results are staggering.

Concurrency Level:    5
Time taken for tests:  1.965 seconds
Complete requests:    1000
Failed requests:      0
Write errors:        0
Total transferred:    5732000 bytes
HTML transferred:    5568000 bytes
Requests per second:  508.90 [#/sec] (mean)
Time per request:    9.825 [ms] (mean)
Time per request:    1.965 [ms] (mean, across all concurrent requests)
Transfer rate:      2848.65 [Kbytes/sec] received

Increasing the concurrency gives even more performance, and even after getting a very large number of concurrent requests it still holds strong.

-c 10
Requests per second:  558.41 [#/sec] (mean)

-c 20
Requests per second:  559.46 [#/sec] (mean)

-c 50
Requests per second:  551.61 [#/sec] (mean)

-c 100
Requests per second:  534.17 [#/sec] (mean)

An increase from #91 to essentially #560 is, in my opinion, mindblowing for delivering a fully functioning, complex page. That would mean the app could theoretically support 48Mil page views/day off a single server, which strikes me as strong performance.


For anyone interested, disabling the CI cache reduced that number to #240 - but still impressive.

John

 Signature 

Proudly making daft mistakes in PHP since 2002.

 
Posted: 23 August 2010 09:25 AM   [ # 5 ]   [ Rating: 0 ]
Avatar
Joined: 2009-03-10
1388 posts

Like I said, 90 is quite slow.

Obviously you can get it higher using DB caching (for a simple implementation look at Phil’s caching Lib), SSD drives (both webserver and database), use of MemCache(d), tweaking your webserver(s) and more tricks. Also client side tricks which reduce the number of requests (HTTP Cache headers, moving static content to a different domain, minimising DNS lookup by setting all paths relative etc.).

 Signature 

Isset | Isset Public Code Repo | Simple Message Library | Session Profiler for CI2.0 | CI session issues in IE

 
Posted: 23 August 2010 09:32 AM   [ # 6 ]   [ Rating: 0 ]
Avatar
Joined: 2010-08-18
24 posts

I didn’t mean to disagree that the original number was quite slow, just commenting that the original 400% speed increase is significant! When you can get another 500% again before database caching, then thats pretty cool. MemCached is the next step, although I’m very very tempted to rewrite the entire database side of things and use MongoDB…

Besides, this is still running on an Athlon X2 QL-65, by the time it resides on an 8 core Xeon then these numbers will go up again.

 Signature 

Proudly making daft mistakes in PHP since 2002.