Massive Performance Issues, Playa and FieldFrame

Have you seen these suggestions? Caching usually gets you a long way.

Yes, I have. We have caching enabled but that only works once the page has been called. Some pages take up to 30-55 seconds to load! Once cached that time drops significantly, but every time an entry is updated or added, the cache is flushed.

Is there some special PHP voodoo that can be added to index.php to add additional insight into what might be causing the delays?

Look at this image and you can see a significant delay in my #1 callout.

Is there a way to determine what exactly is happening there?

There are other options. Above all, use the disable= parameter routinely and generally make sure your templates are as efficient as possible.

Is here some special PHP voodoo that can be added to index.php to add additional insight into what might be causing the delays?

You can turn on template debugging to see how much time the rendering takes, but it looks like you have done that already.

So there’s no other way to tell what specifically is the issue? There has got to be some PHP echo statement that could give some info on the modify_template hook or something.

I’m thinking the reuse of the stock EE relation field for multiple items by Playa is the culprit. I am about to code my own extension that stores the data properly in a proper table (and not a mess of data in a SINGLE FIELD) but I doubt we can do that by Friday.

Is there any way to escalate this? There has got to be a way to get better debugging info…

Hi, iso100 -

Template Debugging, and Showing SQL Queries, is the best option. You might also contact the author. I see you’re also using Mark Huot’s File Extension and we have seen slow-downs with older versions of that, so you might make sure you’re up to date. I understand FieldFrame has a similar plugin that you might consider.

What I would recommend doing is first creating a totally blank template and putting in just

Hello World

and seeing what the speed on that is. If it’s fast, then we can slowly add code back into this test template to find out the exact slow down.

Reeducation testing is the method to test this, let’s first identify the cause of the slow-down before trying to fix it.

Hi Lisa!

We recently (today) switched from Mark’s plugin to the FieldFrame nGen one. It bought us some time back.

We also have other sections of the site (the ones I personally coded, instead of the ones the outside company did (I fought that decision tooth and nail but lost)) that are very fast.

I’ll start some regression testing.

My fear is that the root cause is Playa, for which there is no quick fix other than removing relationships entirely.

If the issue is Playa then you should bring it up with the author. It is, after all, a for-pay module that should have some technical support in this case. =)

But let’s whittle it down and make sure that we’re seeing what we need to.

If the issue is Playa then you should bring it up with the author. It is, after all, a for-pay module that should have some technical support in this case. =)

Funny. We purchased Playa 2 but due to the lack of some changes we made to the 1.x version and the fact that upgrading template code is required system-wide, we haven’t implemented it.

Some initial regression testing seems to point to the nGen File Field we switched to yesterday. Previously, we had Mark Huot’s file field but switched yesterday to nGen’s one. The switch bought us some performance but there appears to still be a hit from the new one.

I will post another update if we make any progress.

Just had a thought… does EE 2 have built-in, proper, multi-relationships?

What I mean by proper is the data stored in a table dedicated to relationships or is it stored in the (IMO) flawed implementation of a single field holding a serialized array of data that must be read in it’s entirety and parsed via PHP each time. (I don’t see this as a fault of EE, but as a questionable reuse of a relationship field that was only designed to hold 1:1 relationships, not one to many.)

iso100, there isn’t any more information available on what is or isn’t going to be in EE2 other than what’s out there already.

Ryan Masuga has an extension for simple relationships, but I’m not sure if that would be helpful in having a more robust version for multiple relationships.

I wanted to give a quick update. We found some inefficiencies in Mark Huot’s Pages Nested Menu plugin and after rewriting and adding some new parameters, the speed has been greatly improved. It was making calls to all weblog fields instead of just requesting the ones it needs. Since Gypsy is being used on this weblog and the total number of fields is very large, this caused a massive performance bottleneck.

Playa is still an issue, but until we can create our own multi-relationship plugin that stores data in a proper multi-row related items table, we can’t solve it other than caching or getting super creative.

One odd thing was that even though MH_File_field wasn’t being used, it was still called in every weblog:entry call across all sites on this MSM-enabled server. We moved to a different plugin and disabled MH_File_field.

so how are things looking now? what is average page load time like? It’s always a good idea to have sql queries & template debugging on while you are developing, as you get a sense really quick if something is going haywire & causing a potential performance issue.

-greg

Average is a tough call. For most pages, we’re looking at a second or so with most being sub-second.

I just had one product detail page take 193 seconds. Yes, ONE HUNDRED AND NINETY THREE seconds. And this is on DEDICATED EngineHosting hardware. Two load-balanced web servers and one dedicated MySQL server along with files on the SAN/NAS. Crikey!

I agree with having Template Debugging and SQL queries turned on. I have to say this though… our company farmed this site out to another agency that had never done any EE work before. My manager felt that my team was too small to handle this task and wouldn’t let me do it internally. You can imagine how I feel about that. Just wanted the record to reflect that it’s not my templating that’s having performance issues. 😉

Oh, and here’s another data point. I refreshed the page that just took 193 seconds and now it rendered in 14. There must be some kind of internal caching going on even though we have it turned off at the tag, query and template level.

14 and 193 are both unacceptable though.