FuelPHP Forums

Hi there, I have a weird request. As a bit of background as to why I want to know this, I have a small webapp that basically stores a bunch of details (server, control panel user/pass, CMS user/pass, emails we hold for clients, notes, etc.) for a bunch of sites we manage for our clients. It works fine, but rather than paginate properly I'm returning all sites to the page as a table and using a textinput at the top as a filtering field and then a small bit of JS to do the filtering. The performance of the page as you'd expect with 1,000 entries is a little choppy in the JS but nothing that'd annoy anyone. However, on a linux box in the office that's not super powerful but powerful enough for most things the page render (FuelPHP) takes >5s, and on my Macbook Pro (2.4GHz i5, 8GiB RAM) it takes about 2.5s. This is unacceptable load time so I'm trying to work out what's going wrong. First off I enabled profiling, and it appears to be just before rendering the view itself (DB query 50-100ms, no biggie there). The built-in profiling wasn't fine-grained enough to know what was going on as it appeared that it's after Request::execute end and before 'End of Fuel Execution'. So that was weird and useless to know. As such, I added a bunch more Profiler::mark calls in my views and in the index.php and it seems to be that the biggest slowdown was between Request::execute (inbuilt Profiler::mark) and the very first line of the view code (I'm using a template here and haven't checked whether it's before the first line of the template, but let's assume it is). Anyway I looked into the request building process and whatnot and I can only assume that my Models are lazy loading (obviously I see this is a good thing, although not for following execution flow!). I'm using ORM and using a simple

$data['sites'] = Model_Site::find('all', array('order_by' => array('site' => 'asc')));

(directly from scaffolding code) to get the data. The call to this appears to be pretty instant, so my guess is that this is lazily loaded. The problem is, I can't quite work out where it's finally loaded. It seems to be before I personally access it (I can comment out all lines in my view (thus never using the data) and it still lags) but the request building and sending process is a weird one. It seems that Request->execute()->response() only seems to run the controller action and lazily load the view when a __toString is called on the resulting Response object's body. (Maybe. This is where I got lost.) My question here, then, really, is what is the flow here? Also, while I know getting everything from the DB and not using pagination is a bad idea, even if I didn't code it as a table in HTML (but instead as a JS object) it'd still lag. The only way it wouldn't lag would be to only return a few at a time, and use AJAX in the autocomplete/filter field, but I like the idea of the instant updates on the page so would rather not go down the AJAX route. So let's ignore my possibly bad design choice, and I'm 99.999% certain it's the DB query but only when loading the view HTML that's the issue (like I said I put in a bunch of Profiler:mark calls even in the index.php file and I noticed the lag right before the bit where it adds the stats (presumably on the call to $response->body() within the call that sets the $response->body(), and if I comment that out, the lag suddenly happens just before $response->send(). But I then gave up working out what happens with this as (as I said above) it appears to use the magic __toString method on at least one of the classes here, and magic methods make it very difficult to follow execution flow! So can someone who knows the internals let me know whether the lag is likely to be the lazy loading of the Models from the DB call (1000ish entries from DB although not an absolute tonne of data) , and if so, what I can do to mitigate that (assuming I can't paginate for whatever reason and I need all 1000 rows. As an addendum, I did try adding a limit to that ORM::find call to 500 and the lag pretty much halve, and then down to 20 and it was unnoticeable, so I assume it is the sheer amount of rows I'm fetching. In fact I've just added a __construct method to my model (with a call to parent::_construct obviously and a Profiler::mark) and I see that that's not the source of the lag either (although is the source of about a second lag in a different bit of the code (Request::execute start and Request::execute end)). Is there something I'm missing here? It looks like it has to be something internal as it's not model hydration, nor is it the big dirty loop in the view (as I can blank out the view and still get the lag) but does appear to rely on the amount of data I'm passing around.