Thread

Hi,

I have a few questions I’m hoping you all can help me with. I’ve already spoken to the support folks at Engine Hosting where I host my site (on an S-3 plan, not one of the smaller shared plans) and I think some of my questions are best suited for EE folks.

Over the last few months I have experienced a number of speed issues on the site. This comes despite multiple attempts to clean up my code and use the best practices lists I’ve been given by both EH and seen here on the EE website. While I do use a variety of third party add-ons, most, if not all, are by major and well respected add-on developers like Solspace, Pixel and Tonic, and Barrett Newton, etc. Plus I don’t feel I’ve gone overboard with the add-ons - we typically use the same number of add-ons (or more) on sites I develop at work. And typically at work I never experience speed problems with my EE installations. These websites however are much smaller in size and scope though - and they receive much less traffic.

My suspicion has been that I may have too many custom fields on my slower personal website. It’s a travel site and I decided to create channels for each type of attraction for the destination in question (Sights, Beaches, Hiking Trails, Dining, etc, etc). All said and done each channel then has about 10-15 unique custom fields, giving me about 130-140 total custom fields. Combined with some other content channels, I maybe have a total of 180 custom fields on the site. This doesn’t seem or feel like an extreme amount to me. I could swear some of my older EE1 sites had more than that and never had major problems. But my site has become increasingly slow - particularly in the backend when publishing or editing entries. Thanks to help from Template Morsels and add-on’s like CE Cache, I have been able to keep the front end fairly speedy (though Google Analytics still reports 4-6 second page load times; far from ideal).

The weird thing is, when I publish an entry, even though I can sit there and count to 30 in some cases, the query count is only around 36 queries and a load time of 0.5622 seconds. I am not especially well versed in reading the Output Profilers, etc - but I’m sure the answer is probably in there as to what’s causing the long load times. It is odd however the execution time is so short and the load time in the browser so long.

My main question is this… should the number of fields I have cause me any problems? And if so, what options do I have to combine them into perhaps a single set of fields where that set of fields is shared amongst all my channels (which is how I should have probably set it up to begin with)? I have thought about exporting the data and then re-importing it, but with 600+ entries using a variety of custom field types, that could be difficult.

Thanks for any help you can provide. Please let me know if you need any additional information on the site or my configuration. I am running the latest version of EE and I do keep all my add-ons up to date. Again, hosting at EH, so I trust them to keep the server up to date. I am going to try Varnish with them to see if that helps, but I’m hoping there are other options for me as well.

-John

First, regarding the slow loading:
It does seem weird that the load time is so much greater than the execution time.  If it’s a “problem” with the database, it presents itself very quickly in the profiler.

Have you watched your network tab of firebug, or the network tab of developer tools in chrome?  I’ve recently seen a missing third-party theme caused a crazy slow load time in exactly the areas you are talking about.  Execution times were normal, load times were 30 - 45 seconds because it was waiting for the files from the missing theme.  If the execution time is short, but it’s taking forever to load… it’s not EE directly - there’s something else going on.

Second, number of custom fields:
Like you, we’ve got a moderate amount of custom fields (we’re sitting at a total of ~250 right now - and we have about 100,000 entries).  The shockers for me about the MySQL DB in EE are:
1.  using text fields for nearly all inputs
2.  no indexing of any custom fields

I’m constantly changing the configuration of the fields in the DB to make the system run at least a little more efficiently.  Changing a “text” to “varchar” and indexing fields… totally changing the dynamic and speed of many areas of our system.

Additionally, there are some standard slow queries that EE has that I’ve been able to work around.  For example, if the title of an entry is the same as another previous entry, it will do a very slow (~0.3 second) query to calculate the next incremental value for the url title.  0.3 seconds isn’t bad, when it’s one or two records.  But we had customers importing 10,000 records… which then creates a very very slow process.  We created a workaround by concatenating the URL with a random string to prevent a duplicate title.  We shaved a lot of time off the processing of those records.

These slow queries show up normally in the system profiler - which is the best place to live for the optimization part of the conversation.

I hope this helps, I’d love to continue the dialog and help each other find ways of making our systems faster.

Just tried with Firebug on the Network tag. The longest loading time took place on a POST request, at 21.9 seconds. Gave a 302 Found status.

Looked something like this:

<a href="http://www.ourdomain.com/EE">http://www.ourdomain.com/**EE</a> DIR**/system/index.php?S=**session**removed**&D=cp&C=content_publish&M=entry_form&channel_id=15&entry_id=54&filter=YToxOntzOjEwOiJjaGFubmVsX2lkIjtzOjI6IjE1Ijt9

I need to get better at reading these types of things. Does that provide any insight into what’s hanging it up?

I don’t see any references to missing themes… I usually keep those pretty up to date. One thing I did see taking a while to load however was the Google Maps API on the Edit Entry screen, bc I use MX Google Maps. But that page still loaded WAY faster than the entry confirmation screen after hitting Submit.

I suspect my custom field count is probably OK then based on what you’ve said.

that looks like it’s the call to the main document you’re loading… (it is at the top of the list of requests, right?)

if that’s the case, it looks more like a server-side issue (not what I was alluding to earlier)

I’m glad to help diagnose the profiler results in private, if you’d like.

Hi John,

Thanks for the great post!

Just tried with Firebug on the Network tag. The longest loading time took place on a POST request, at 21.9 seconds. Gave a 302 Found status.

Based on the URI string you supplied, it look related to the “filter” argument. Are you using any third-party add-on that works with the publish page specifically?

Cheers,

Hi Dan,

Thanks for getting back to me. I can’t think of anything off the top of my head that is specific to the publish page, but let me run through all of my Extensions again just to make sure. I used to utilize Publish Redirect, but since it didn’t work with Cartthrob I had to shut it off.

I’ll get back to you on what I find.

Thanks again,
John

The one add-on I did have that was working with the publish page was the Sitemap module. So I disabled it and it seems as if now my page loads are taking even longer - which strikes me as strange.

The output of the page looks like this:
BENCHMARKS
Loading Time: Base Classes   0.0119
Total Execution Time   0.7404
Controller Execution Time ( Content Publish / View Entry )  0.7302

But I seriously sat there and watched it take almost two minutes for the page to actually load in the browser.

This is really puzzling to me… it’s as if it’s submitting quickly, but taking forever for the POST request to actually go through for some reason.