Haensel and Da:Sourcerer made excellent posts covering the OP’s questions and concerns. But one thing is missing: the problem is not with Yii, but where’s it?
I still believe that those 40 requests are the problem.
The major factors I can think of:
The number of concurrent connections per hostname.
The overhead of the multiple application environment setups, as explained by Maurizio.
To wrap up, the problem isn’t Yii, as explained, but how it is being used. You have some options:
Review your frontend design to get more data in less requests. Or even deliver a complete page in one request.
Use page caching. You can go further and save the generated js file to a directory checked by your Web server and skip PHP and the framework entirely for the cached items.
The last suggestion for what might help you is to hire an experienced Yii developer to take a closer look at your issues and suggest the fixes.
As far as I know the programmers use a minimized version of ext-all.js, and use then also use the neptune theme. I can find out tomorrow if there are more.
One thing is speed of framework, but other thing is proper web application architecture. What is ok with desktop application will not work as well in web-based one. There is something called "latency" of network and having this in mind you have to project proper granularity for requests from HTML/Javascript to backend. This has nothing to do with Yii, PHP or any other technology. If your application needs 30 requests to display single screen - it will not work fast event if you use alien technology for backend which answers in nano-seconds. the latency of network links will kill you. First thing you should consider is to reduce requests to as low as possible (ideally there should be single request which responds with all needed data aggregated in one package).
To everyone - just to say thanks for your posts - were all very helpful!
To summarize the answers so far, it seems the causes of the very slow page-opens are the following:
Issuing multiple request (40 times) – each request requires certain “setup”/configuration code to execute and each request also has network latency built into it.
The inherent design nature of a single page app with REST and AJAX issuing requests may impede performance.
Lack of oppcode and other (eg. data) caching mechanisms
Configuring main.php to import only neccessary stuff.
Implement yiilite (we already use a minized version of ext-all.js)
The database can’t be the issue since we’re testing with single, unrelated tables with less than 100 records and the sql queries are all very simple.
they should be minimal in local scenario, but anyway - every http call needs some overhead: preparing http call, send data to server, parse request on server side, pass control to PHP, execute PHP application stack, and so on. You must understand that HTTP is by design stateless (of course there some workarounds like server side session), meaning that on every request application state is rebuild from data passed every time from client and some local storage data (session, database, etc). So fewer request you made - faster results.
You could compare it to situation when in desktop application to make any mathematical calculation you have to call windows Calculator, instantiate new process, do the calculation and destroy Calculator application. Even if your application is fast and Calculator itself is also pretty fast - total result is performing really slow…
I disagree on these points. A yii webapp can easily handle these amounts of simultaneous requests, and more. If it can’t, it might be wise to look at your server setup and/or configuration.
once i had an issue where some yii pages (for example, about 200 records being shown on a cgridview) took very long (15secs +) to load.
I expected the bottleneck to be in the database of course but, when I profiled my app (using xhprof) i noticed that the bottleneck wasn’t the database, but regular page rendering.
At last I found the culprit: it was the htmlpurifier.
It’s very slow if you need to display a lot of data, so if you do any sort of output filtering i would definitely tell you to test your app with no output filtering to see whether it’s the source of the problem.
even today i’m very wary of using htmlpurifier on a page, i only use it when i’m certain there won’t be a lot of data other it is a drag.
HTLPurifier is used by default to prevent XSS attack even when programmers are lazy and forget about proper input validation and filtering. If you are aware of such attack vectors and filter your input well - using purifier when rendering is indeed an overhead. You can simply disable it for every column adding ‘type’=>‘raw’ (or any other needed type but ‘html’) to its definition
Just one more consideration: even in local environment you can experience a small round trip time on the httprequest, that grows with distances.
Usually a rtt of one second is not felt from the user, as it is compliant with normal page loading time.
If you need 40 requests for create a page, and 40 serial request, not parallel, even a rtt of 250 ms will translate in a 10 second delay, and that is only the time needed for start the request, not counting php overhead.
