[Eric Kennedy]

I first heard about Yii on March 19th, and by the end of April we had migrated our website from Drupal to Yii. Yii was a big improvement in clarity and speed.

These charts show that the Yii performance benchmark using Hello World really does translate to real-world performance.

There are a lot of Web 2.0/social sites that started on Drupal and have outgrown it. I hope that many sites running Drupal or an older PHP framework see this Yii versus Drupal performance comparison and consider switching to Yii.

Please share or tweet this so more people find out how well Yii scales to a site with more than a million unique users. If you have questions, just ask me.

Attached File(s)

•  yii-cutover-stats.png (36.29K)
  Number of downloads: 1512

[jacmoe]

Wow, that's impressive!

Even if you consider the fact that you probably improved the app by porting it - refactoring does something to an app (usually) - it does look really good in Yii's favor.
Thanks for sharing - and congratulations on a succesful mission.

[qiang]

Thank you for sharing your real experience with us. I also enjoyed your writing. Good job!
Just tweeted it.

[Eric Kennedy]

Thank you for creating Yii! We really appreciate it.

The post is also on Reddit, so please vote it up so more people find out about the benefits of Yii.

[samdark]

Really nice writing. Thanks for contributing back to the community.

Nice trick with imagecache-like plain PHP script.

[fastcrash]

woow.. Subarashii na!
i will bookmark the link.

i have myhand on drupal7 right now.. for the seek of my perfect cms
i will think about it..

thanks

1000.000 visit? woow your site is really something..

are you using round corner script?

[Eric Kennedy]

We use pure CSS for the round corners so the corners are square in Internet Explorer 7 and older.

Here's the CSS code for a DIV with class="floaty"

.floaty { background: #FFF; padding: 15px; margin: 0 0 1.2em 0; border: 1px solid #C5C5C5; 	
      border-radius: 5px; -webkit-border-radius: 5px; -moz-border-radius: 5px; }

[samdark]

CCK = CSS in the last post. Eric Kennedy, looks like you've Drupal-ed for too long You can add -khtml- to a list of border-radius prefixes to support some Linux browsers.

[Eric Kennedy]

Thanks for catching that. Late night posts with a lack of sleep...

[fastcrash]

Eric Kennedy, on 02 December 2010 - 03:23 AM, said:

.floaty { 
  background: #FFF; 
  padding: 15px; 
  margin: 0 0 1.2em 0; 
  border: 1px solid #C5C5C5; 	
  border-radius: 5px; 
  -webkit-border-radius: 5px; 
  -moz-border-radius: 5px; 
}

thank you!

[yiimann]

Maybe you didn't have any cache in drupal or It wasn't that efficient.

[Eric Kennedy]

yiimann, on 05 December 2010 - 09:11 AM, said:

Maybe you didn't have any cache in drupal or It wasn't that efficient.

We used Drupal's built-in caching system and spent a lot of time in 2009 rewriting queries, adding cache tables and adding cache columns to Drupal's existing tables. We use rewritten URLs (/Lasik/reviews instead of /node/421) for everything and by default Drupal's l() function does a separate database call to get each rewritten URL. So months before we switched to Yii we had already replaced all references to the standard l() function to avoid those extra database calls.

Yii is faster than Drupal and the older PHP frameworks because it uses "lazy loading" to only load the capabilities needed to build the current page. In contrast, Drupal loads every enabled module and checks if that module has a function (a "hook") to modify the current page.

160 milliseconds is a decent request-and-response page download time. Most sites load up their site with so many separate image files that the total download time is over 3 seconds, in which case a 90 millisecond difference in page download time doesn't matter that much. We already used CSS sprites to put icons in our logo file so the only option left to speed up our site was to render pages faster.

The problem for us was that we were spending about a third of our time tuning Drupal to get it to that speed, and it was frustrating work. We had a lot of other functionality we needed to work on so that time could be put to better use. Now that we're on Yii we can focus completely on better functionality without having to worry about tuning and scalability.

[binkabir]

Hello

thanks @Eric Kennedy
i seems to really enjoy all ur analysis thanks once again
but did u use any of the php caching modules like APC or eAccelerator ??
to get these results in ur graph??
really incredible i love ur site

[Eric Kennedy]

Thank you. We have used APC under Drupal and Yii and it reduces the page render time significantly.

[Trejder]

Eric,

Your information and especially graphs showing DB operations and performance are really, really impressive! Congratulations on having business grown that far and dev team able to write application to process it!

Can you be a little bit more specific on about DB operations topic? Can mention some numbers on what percent of DB-related operations in RealSelf.com are done via ActiveRecord and how many via DAO? Do you see any serious performance degrade / difference between these two methods? Are there any parts of code that are using pure PDO object, leaving all that comes with Yii behind?

I will appreciate all your answers as currently I'm developing a bit large project that uses both DAO and AR for connecting to Oracle and even at very early stage of development I can notice a huge overhead in performance in favor of DAO. ActiveRecords is by far much, much easier, but performance degradation using it is really noticeable.

P.S.: I haven't been using any caching method so far (planned to introduce at later stage of development), but I believe that it can only speed up both accessing methods. It should not (at least in my opinion, maybe I'm wrong) change difference between DAO and AR.

[Trejder]

Here are may results on currently developed application (no cache), if someone would like to compare performance.

Inserting new records:

Done adding 100 records using PDO! Affected rows: 100. Execution time: 0,65056991577 seconds.
Done adding 100 records using DAO! Affected rows: 100. Execution time: 0,51093888283 seconds.
Done adding 100 records using ActiveRecord! Affected rows: 100. Execution time: 4,36565303802 seconds.

Selecting records:

Done selecting 116 records (160 columns) using PDO! Execution time: 0,00221800804 seconds.
Done selecting 116 records (1 column) using PDO! Execution time: 0,00229716301 seconds.

Done selecting 116 records (160 columns) using DAO! Execution time: 0,01175117493 seconds.
Done selecting 116 records (1 column) using DAO! Execution time: 0,00211501122 seconds.

Done selecting 116 records (160 columns) using ActiveRecord! Execution time: 2,49749708176 seconds.
Done selecting 116 records (1 column) using ActiveRecord! Execution time: 0,01181292534 seconds.

We can see an large performance degradation, when using AR, but what is surprising (at least for me), we can also see slight better performance of using DAO over PDO.

[qiang]

Make sure you turn on schema caching for AR. Otherwise, a lot of time in AR would be spent in retrieving schema information. With proper configuration, AR should lower the performance of DAO/PDO by 50% or less.

[Trejder]

qiang, on 09 December 2010 - 11:38 AM, said:

Make sure you turn on schema caching for AR. Otherwise, a lot of time in AR would be spent in retrieving schema information. With proper configuration, AR should lower the performance of DAO/PDO by 50% or less.

What do you mean by "proper configuration"? Is setting schemaCachingDuration to a large value the only thing to do or using caching component and configuring schemaCacheID is also obligatory?

With only schemaCachingDuration set, I got results like:

<tt>Done selecting 300 records (160 columns) using PDO! Execution time: 0,00766205788 seconds.
Done selecting 300 records (1 column) using PDO! Execution time: 0,00710415840 seconds.

Done selecting 300 records (160 columns) using DAO! Execution time: 0,01816511154 seconds.
Done selecting 300 records (1 column) using DAO! Execution time: 0,00933790207 seconds.

Done selecting 300 records (160 columns) using AR! Execution time: 2,38169789314 seconds.
Done selecting 300 records (1 column) using AR! Execution time: 0,05867600441 seconds.</tt>

Therefore I can't observe any noticeable performance upgrade with it. Times are comparable (aprox. 2,5 second for selecting 116 records/160 columns and aprox. 0,01 seconds for selecting 116 records/1 column).

Another question. What is the reasonable value for schemaCachingDuration? If I have constant table schema, is it good idea to set this property to one day (86400 seconds) or even more?

[Mike]

If you can't see any significant improvement, you seem to miss a cache component. Because, if you want to cache something you (obviously) need such a cache that holds the data for you (CApcCache, CMemCached, ...).

[Trejder]

Mike, on 10 December 2010 - 04:18 AM, said:

If you can't see any significant improvement, you seem to miss a cache component. Because, if you want to cache something you (obviously) need such a cache that holds the data for you (CApcCache, CMemCached, ...).

Yes, this is obvious. I misunderstood the guide. Since there is no information around schemaCachingDuration that use of schemaCacheID is explicitly required (can be obvious for some and not so obvious for others, especially - like me - not experienced in caching subject), I thought that CDbConnection uses some internal caching techniques, which can be enhanced by providing schemaCacheID as alternative (not primary) caching engine.