Massive Performance Issues, Playa and FieldFrame

teehee 😊

I understand. Running hardware like that, you should be screaming fast 😉 With that crazy template, definitely look to see how many embeds you have. Are there nested tags? Are you using a bunch of plugins on the page? Extensions at play? Are you disabling everything you can, etc.

Make sense?

I can post a detail template, but not sure what to do about other embeds. Should I just send them up too? Exclude global navigation, footers, etc?

Greg, when we turn off all the features of the page, it’s screaming fast! A bit light on the content and features though.

iso100 - hrm, it may be a bit complicated for us to look at.

If turning off the features speeds things up then that very effectively rules out a core EE slowness and definitely points to your templates as the issue. The way I would troubleshoot this is to start with a bare template, then slowly add code back in until you find the cause of the slow-downs. You may need to do a fair bit of trial and error depending on the complexity of the template. But there is going to be something in there that is causing this, and once we know the exact snippet we can tackle it head on.

Certainly the developer did some testing as he built it out, no?

I’ve done some regression testing and nailed down two extensions that seem to be causing issues:

nGen File Field (via FieldFrame) and Playa

Over the course of the last 24 hours things have gotten slower and slower on the detail pages with lots of related fields. In looking at the Manage Database Tables view, I noticed that exp_relationships was up to 800+Mb. After running Optimize Tables on it, we’re back down to 532Mb for the 12291 records within. This has also brought the performance back to an acceptable level (for most pages).

Can someone explain what Optimize Tables really does and possibly shed some light on why this table keeps growing?

Optimize tables is not EE specific, it’s just a database way to clean the tables. It’s available in PHPMyAdmin as well; honestly, I’m not sure of the nitty gritty of what it does.

You can also go to Admin -> Utilities -> Clear Cached Data and clear your relationship caches if needed.

I am wondering if it’s just one of those extensions or the combination of both. I would definitely contact the authors to further troubleshoot what might be going on.

I was afraid of that. I’m now at the mercy of the developers of extensions offered up for free. 😉

At least with Playa you could upgrade to 2, which I think you said you already own? That is commercial so should be supported. Heck, it may even work out of the box with nGen field frame…. I’d imagine so since that is its first requirement:

1. Install FieldFrame 1.0.5 or later

Just a thought…

I guess that’s one option, but no way to know if it will resolve the issue. Additionally, Playa 2 and 1 can’t coexist, so we’d have to update all the templates on all the other sites on this MSM server to support the new Playa 2 template code. Also, Playa 2 currently lacks some customizations we made to 1.3.3 that support site/weblog/category prefiltering at the time of field configuration.

Nothing is easy, is it?

Well, some things are easy. This one sounds a bit not easy.

In any case, you have several potential paths to take here. Perhaps you could discuss some of the issues with the authors and see what they think. In the mean-time, I’m going to shift this down to the extensions forum since that is the appropriate place, given your findings.

I’ve also retitled it for clarity.

Our pages are fast until the table size for exp_relationships starts climbing. Does anyone know if it’s possible to turn off the addition of data to the rel_data field in the exp_relationships table? As soon as the table starts approaching 700mb or so (which happens very quickly) our peformance suffers massively.

I just got done reading this: http://expressionengine.com/wiki/Relationships_-_Under_the_Hood/

Is there any way to temporarily (or permanently) disable EE’s creation of the rel_data and reverse_rel_data cache fields? It is this data that is causing our exp_relationships field to blow up to over 750MB in a short amount of time. I believe the size of this table is affecting query performance in a sort of snowball effect. Up to a certain point, the cached data seems to help things. After it gets too large, however, it seems to slow down again and the act of rebuilding that entry’s rel_data cache causes that page load to be very slow.

Clearing cached relationship data and optimizing the table brings the size down to 203MB. Using the site though quickly (within a few minutes) brings the size back up over 500Mb.

I’m checking with the team on your latest comments, iso100. I’ll get back to you once I have more information. Likely the soonest will be Monday at this point.

This is a really interesting problem that iso100’s reporting. Given the overall attention to detail that’s gone into making Playa and Playa 2 usable, I’d think Brandon Kelly would be glad to hear iso100’s suggestions on how to improve performance. Got to say, though, that I haven’t myself encountered these performance issues. His site must be orders of magnitude larger and more complex than most.

I had an issue similar to this and I thought it was due to Playa 2 (mainly multiple relationships), but looks were just deceiving.

Turns out I was using advanced conditions to serve up different sets of relational data from the same weblog. Because of the parsing order that EE parses data, all of my conditions where actually being executed although only one was being displayed. I solved this by moving each condition to its own template and then embedding them because the execution of the embed actually takes place after the execution of the conditional.

Example of my new code:

{if condition a}
     {embed=subtemplate/a}
{if:elseif condition b}
     {embed=subtemplate/b}
{if:else}
     {embed=subtemplate/c}
{/if}

Then, my subtemplates each have their own queries of weblogs that have large relational entries.

I don’t know if this helps in your situation, but I someone comes across this thread looking for a solution to this problem, I hope it can help.