Yii Performing Poorly

Hi!

Is it normal that a project in Yii, when subjected to a load test of 2000 users in 10 minutes, gets 30.2 sec per request and chokes the server?

The project is not using any cache mechanisms, and the time per request with only one user is about 0,370 sec.

Thanks!

I think it is quite normal to any php framework (especially when not using cache)… but it may depend on the server strength. 2000 concurrent users is quite big load for PHP and single server (~4cores serving both www and dbms backend) probably won’t handle it. We developed a site capable to handle even ~4000-5000 simultaneous users but with loadbalancing to few machines handling php requests and another one as sql node…

Thanks for the reply redguy.

What’s bugging me is that the project in Yii is very similiar to another one, developped in a smaller framework. And when tested in the same testing conditions (same server, same accesses to the same database, also no caching mechanisms), it had a time per request of 0,610 sec…

Also, as far as I know, the server in which the test was run is composed of 4 nodes with built-in loadbalancing, so I guess that the server may not be the issue here.

There are frameworks that have really small footprint, but they also do not have features like Yii. There is also native MVC implementation for PHP (written in compiled C as extension). So it is hard to compare.

If there is LB on 4 nodes then you are right that it should work much better, but you have to tune it and find bottlenecks. Maybe they are not in PHP/Yii but for example missing indexes in DB, which works fine in dev but when there is more data - causes lags. Try to turn on profiling in Yii and check if you can reduce request processing time. Also - check which requests take longest and focus on them.

Right, thank you redguy.

I rechecked with profiling (even used the extension yii-debug-toolbar) and everything looks ok…

The test involved a couple of heavier requests, two pages that have multiple (i mean, seven) database requests, and those are taking about 0.304 sec (or less) … And with one user, the time per request is around 0,560 sec.

If the problem was in the DB, then I think the project in the smaller framework wouldn’t perform so well, and I would be able to see it with profiling, right?

I’m actually really frustrated, because the project is quite simple, there aren’t any heavy processing in the backend and there is also very little room for mistakes in my opinion…

not exactly… i.e. if you do not have db indexes then dbms is doing full scan on such table to perform any query. For single user - this will work (slower than it could work, but anyway…) in multiple user scenario - disk IO will become bottleneck and dbms won’t handle mamy fullscans simultaneously on large tables.

try for example this: http://www.yiiframework.com/extension/csslowlogroute/ and run load test.

I’m going to check it, thanks!

PS: Not wanting to be annoying, but I’m still thinking that the other project in the smaller framework would struggle with that too, no?

hard to tell, like I said. I am not saying that Yii is the best in every aspect, but I have seen site written in Yii handling few thousands of users on stress tests :) I think it all depends on how it is written…

I tested the extension, and i only got warnings when logFrequent => 1 , like the following:

014/09/23 11:18:31 [warning] [slowlog] Procedure: (…) Count: 1; Total: 0.00029; (…)

, which makes sense…

try disabling debug mode in the config and

set schemacaching for the db = 0, also

use the APC extension as that will increase the request per page.

Another thing to look at is fragment and page caching, because if

you can cache certain parts of the page it will improve performance.

Also have a look at the performance page for further details.

http://www.yiiframework.com/doc/guide/1.1/en/topics.performance

also do some profiling on the application using xdebug profiler

http://www.xdebug.org/docs/profiler

you mean "set schema caching to sth greater than 0, like 606024". Setting schema caching to 0 will disable schema caching, which is not good for performance…