Benchmarking Yii

Archives Yii 1.0.x Discussions
1

I firmly believe this topic will attract some people, as it should examine Yii performance capabilities.

We all know, it is very hard to keep benchmark results near to numbers shown in performance chart, but we can do our best to achieve maximum performance without aggressively caching every function return value.

I made quite an impressive progress in my website development, so I was able to measure a couple of things.

  • Apache 2.2.11

  • PHP 5.3.0 TS, VC6

  • MySQL 5.1.36

  • 2 Gb ram

  • Intel Dual-Core 1.86 Ghz

  • Windows 7 x64 (psst!)

  • Latest wampserver (2.0i)

  • Caching & APC disabled

I always measured real usage. Please see the corresponding manual page to see what that means.

My findings were:

  • Because PHP was not in CGI mode by default, approximately 0.5 Mb memory consumption showed up in the very beginning of each request. This may change due to enabled php extensions (I have xdebug for example). I substracted its value from the final result.

  • I configured my urlManager to have 27 url rules so far. According to the guide this can cause performance loss when lots and lots of urls are auto-generated. This, at least in theory, only increases the time spent to generate output, and basically doesn’t have effect on memory usage. Apart from this, I don’t have many components (db, dummy cache, 3 log routes, session).

  • Instead of onBeginRequest, I used beginProfile at the top of my config file. This might better represent the data we want to examine, because it covers more script. However, I was not able to put endProfile beyond onEndRequest without extending base classes.

  • Db-less pageviews normally render within 65ms - 90ms. Others need 100ms - 300ms.

  • Memory usage vary upon action complexity and classes involved. Peak usage measured at onEndRequest is very near (or equal in many cases) to current usage at onEndRequest. This probably means that Yii does not free up unnecessary class instances. After all, it’s a job of onEndRequest (or ultimately PHP’s garbage collector), but I’m quite sure there are ways to lower memory consumption.

  • Overall memory needed to perform each request was between 3,6-5,5 Mb in my case, which sounds reasonable.

  • I also ran some ab tests, my front page performed between 9-13 requests/second, which is a bit worrying.

Apart from the tips in the guide, I look for Yii-specific advices to reach the speed of the light. :)

In this attempt, I’d also love to hear your opinions. Not only numbers and benchmark results, but ideas to keep Yii in its best condition.

If this is possible, I would also like to measure the core performance and remove all bottlenecks before the next major version gets released.

2

You should enable APC to test. Otherwise, your result won’t have much sense because it doesn’t represent production situation. Also, without APC or other bytecode caching, the overall performance is affected significantly by the number of PHP files and their size involved in a request.

3

Currently I have one free and one paid hosting (both shared). Neither of them support APC or any other bytecode caching. And this is not a rare case in Europe.

However, even with having those at hand, Yii still has room to improve in terms of performance. I love to see features being added to my beloved framework, but You know too, all newly introduced methods come with a price.

With all due respect, may it be possible to run benchmark tests on the core?

4

A little offtopic but OpCode caching is truely awesome. On my dev VM i get ~200r/s with xcache vs. ~50r/s without xcache on a hello world application (with some of my custom components loaded though). Currently I’m running PHP 5.2.8 (lighttpd 1.5 via fcgi). I guess a change to PHP 5.3 will speed things up even more - will try that out soon.

On the topic itself I can’t say much yet. Yii is my first framework and I basicly just started to develope my first (huge) project. When it’s done I may come back here and share my knowledge. But from my past experience I would say that the db-queries are the bottlenecks mostly. I think PHP memory usage for example shouldn’t be a problem for most projects. But I may change my mind about that.

5

We actually did many profilings about Yii using xdebug to find out where the bottleneck is and optimize it. If I were you, I would not be worried when seeing 9-13 requests/second for the front page because there are a lot more that you can do at the system level to improve this number dramatically. I also believe you can reduce the number of your url rules (you may show them here so that I can see if they can be simplified.) Also, you should set YII_DEBUG to be false so that it doesn’t record unnecessary log messages.

6

That’s great news. If I knew this, this topic probably would not have been opened and I let professionals do the job.

Here’s my list of rules:




''=>'site/index',

'helyszinek'=>'rpg/overview',

'helyszin/<place>'=>'rpg/viewplace',


'forum/tema/<topic>/hozzaszolas'=>'forum/reply',

'forum/tema/<topic>'=>'forum/listposts',

'forum/<board>/uj-tema'=>'forum/newtopic',

'forum/<board>'=>'forum/listtopics',

'forum'=>'forum/listcategories',


'meghivas'=>'site/invite',

'jelszomegujitas'=>'site/forgottenpassword',

'bejelentkezes'=>'site/login',

'kijelentkezes'=>'site/logout',


'karakter/alkotas'=>'char/create',

'karakter/<char>'=>'char/profile',


'jatekos/regisztracio'=>'user/register',

'jatekos/modositas'=>'user/editprofile',

'jatekos/karaktervaltas'=>'user/changecurrentchar',

'jatekos/<nick>'=>'user/profile',


'sugo'=>'faq/overview',

'sugo/adminisztracio'=>'faq/adminquestions',

'sugo/<question>'=>'faq/viewquestion',

'sugo/<question>/adminisztracio'=>'faq/adminquestion',

'sugo/cimke/<tag>'=>'faq/viewtag',

'sugo/adminisztracio/hozzaadas'=>'faq/adminquestion',


'adminisztracio/moderacio'=>'admin/queue',

They are mostly aliases as I use strict parsing and would like to provide urls in my native language. In case you can help, I greatly appreciate.

I believe that without complex regular expressions and additional params, this set of rules has insignificant performance impact on the website.

Thank you for your support and help.

@Y!!,

Thanks for your reply. As you can see, I didn’t know much about the core development either, but this forum is for discussing topics regarding Yii, isn’t it?

Memory usage is probably not a bottleneck in most cases, but as a framework for web 2.0 development, Yii should concentrate on lightness and responsiveness in my opinion.

7

Yeah, I can’t find a way to optimize your rules. They should be at the current limit already unless you are willing to modify the names of some actions.

The reason I kept saying enabling bytecode caching is because it is the simplest and most feasible way to improve your app’s performance. Without it, you would be worrying about why you should put code in separate files since they will definitely degrade your app’s performance.

On Yii’s benchmarking page, the hello world takes about 10ms when APC is disabled. This is comparable to your number 65-90ms, considering the fact that the benchmarking machine is more powerful and your db-less pages are more complex than hello world (involving URL parsing, logging and view rendering).

Regarding memory usage, the majority memory consumption is usually by storing DB query result. In general, if you use Yii DAO, there should be minimal memory overhead. If you use AR, the memory overhead is about 100 bytes (or less) per AR object. I think the verdict "Yii does not free up unnecessary class instance" lacks sufficient evidence.

8

Thank you for sharing your opinion. I better change hosting provider to obtain speed boost due to bytecode caching.

It is exactly the reason why I left Zend framework behind.

Thanks for putting so much effort to express your point of view, and forgive my ill-breeding, if I was at some point.

9

Interesting. For the benchmark (yii 1.0.3), I get aprox. 2,750 rps on an old-ish laptop. Running a regular Yii default app source page is approx. 2,550. This plummets to 37 rps when I add a database using a default list action (table has 8 rows). Latter two on yii 1.0.7.

  • Apache/2.2.11

  • PHP/5.2.6-3

  • 2 Gb ram

  • Old Intel 1.8GHz Celeron laptop with slow 5400 disk and loads of services and apps running

  • Ubuntu 9.04

I’ll run this on my slice-based hosting later. It’ll be interesting to cachegrind this too.

10

If you are using AR, you should consider enabling schema caching. Otherwise, a lot of time would be spent in reading table schema information.

11

Yes, tried ‘schemaCachingDuration’=>3600, but it only made a small difference. It’s probably just poor disk management somewhere in the chain; not usually an issue for a laptop. I’ll fiddle about a bit more just to verify.