Thread

The results from a fairly standard entries loop results in the fatal error: “Fatal error: Maximum execution time of 90 seconds exceeded in \sysadmin\expressionengine\libraries\Extensions.php on line 179”. It’s supposed to output about 1000+ entries, which I suspect is the root of the problem.

Although I don’t think the code has much to do with it, this is what is being used:

{exp:channel:entries channel="foodbank" orderby="title" sort="asc" disable="member_data|pagination" dynamic="no" limit="9999999999"}
{title}
{crossstreets_foodbank}
{hours_foodbank}
{phone_foodbank}
{fax_foodbank}
{website_foodbank}
{languages_foodbank}
{eligibility_foodbank}
{additional_foodbank}
{sortcity_foodbank}
{county_foodbank}
{contact_foodbank}
{email_foodbank}
{altphone_foodbank}
{primarycustom_foodbank}
{agencysource_foodbank}
{updatemethod_foodbank}
{updateprovider_foodbank}
{/exp:channel:entries}

I’ve experienced the same sort of problem before - 1000 entries in a single loop has seemed to be too much for EE to handle.  If you drop it to something like 500 I take it you don’t get the error?

The way I’ve gotten around it before in the past it using Solspace’s Template Morsels - which effectively allows you to break your entries loop into parts and cache the result of the loop in the database.  Which means you get around the limitation while also speeding the whole page up significantly because it loads from the database cache of the loop chunks. And you get set the cached morsel to break and be reformed with a rule like a new entry in the channel, for example.

Hope that helps.

Unfortunately I don’t think the client will spring for a paid plugin. I’ll look into it for sure. I found that disabling the playa, assets, and matrix extensions saved about 3 seconds. But that is nothing in comparison to EE’s 45-50 second load time. This is looking more like a straight up EE issue, which is what I suspected. Here is the debug:

(0.067732 / 6.80MB) Beginning Final Tag Data Processing
(0.067766 / 6.80MB) Calling Class/Method: Channel/entries
(0.068081 / 6.81MB) -> Class Called: Channel
(0.078643 / 7.00MB) -> Method Called: entries
(45.304384 / 11.36MB) -> Data Returned
(45.305858 / 10.81MB) - End Tag Processing -
(45.306256 / 10.93MB) - End Template Processing -
(45.306269 / 10.93MB) Parse Global Variables
(45.317681 / 10.93MB) Template Parsing Finished

As you can see, the delay is right before data is returned. I think the simple volume of requesting 1000+ entries is too much for EE. Is there anything besides a 3rd party add-on that can remedy this? Would using a custom query alleviate the load at all? I’m guessing not, since its a db request either way. Cacheing the tag via the EE parameter seems to do next to nothing.

Also, to solidify the point that I think it just can’t handle the entry load, I kept adding fields one by one, and each time the load speed was increased. With just the {title} field resulting in only a 3 second load, and 4 fields total resulting in a 13 second load, and all of the fields in the 45 second load you see above.

Yeah i think the problem is that it simply takes too long for EE to retrieve 1000 records with that number of custom fields.  A custom query would help only if you didn’t need all those custom fields - then it could loop through the data and only grab those that match your needs - but if you need all of those fields for every entry, it likely wouldn’t make much of a difference.  That many entries required from a single loop is probably at the core of your problem. if you were able to break it up and cache them - particularly separately - you might do better.  A third party add-on may be the most effective way to do it.

Are you actually looking to display 1000 records in a single page? I noted that you have pagination disabled.  But categories are not disabled.  Are you using categories to provide a breakdown of the 1000 entries?

The 1000+ records are basically an export of entries in an XML template. So it’s not necessarily display. I can’t use standard XML export plugins because the XML template is arranged in a specific format the client requested.

Ah - that being the case, what if you try chunking it into a few segments, caching each one?  I wonder if that might help?  Something like:

{exp:channel:entries channel="foodbank" orderby="title" sort="asc" disable="member_data|pagination" dynamic="no" limit="500" cache="yes" refresh="60"}
{title}
{/exp:channel:entries}

{exp:channel:entries channel="foodbank" orderby="title" sort="asc" disable="member_data|pagination" dynamic="no" limit="500" offset="500" cache="yes" refresh="70"}
{title}
{/exp:channel:entries}

You may need more loops than that for this to work, but you get the idea.  Two (or more) loops that with limit and offset cumulatively add up to your full list.  Since you’re not displaying on the front end, you MAY be able to get away with this.  I’ve never tried it, but it’s probably what i would attempt anyway.  And if categories aren’t needed, I’d disable them too - whatever you can turn off from the loop will help.

Hope that helps.

I’ve used a flat file PHP file with a custom query to output the entries instead. It’s more of a work around than a solution, but the flat file execution time (about a second) makes EE’s execution time look like Wolf Blitzer on heroin.