Alright; I think that the templates are going to end up being a huge part of your problem. On your main index I counted, I believe, 19 weblog entries tags and that doesn’t include whatever you have in all of those embeds. Furthermore, you have embeds within your weblog entries tags, so say you are showing 10 entries, that embed will occur 10 times. Depending what’s in the embed, you could be really weighing the site down.
More concerning to me is that you have opened up some potential security issues in your templates. You have code like like this:
{if "{segment_1}" == "seccion"}
See how your segment_3 variable is quoted and braced? That is unnecessary and, since it can take user input, it is a security issue. Please read Troubleshooting Conditionals to understand more about this.
At this point, I would recommend a complete template audit to optimize and figure out better ways of approaching the display of your data in a much less intensive way.
I didn’t see any tag caching in the templates (but lots of disabling unneeded data, which is perfect) and not any mention of it in this thread, but I assume you’re caching the heck out of your templates?
And, yeah, there’s a ton going on with these templates. I’d concur with Lisa that they need to be re-evaluated and optimized. This may be a case where you don’t cache the entire template, but cache at the tag level for certain items that rarely change over the course of a day.
Right now with a slower load on the server, the home page is loading in under 10 seconds… this morning it was loading in 60+ seconds.
Yeah, with little load, you should be much, much faster than 10 seconds. Just so you know, MySQL will be your first bottleneck and CPU hog under heavy load. That’s why caching is so important.
Ryan has a point, most of our users come complain if page loads are over 1 second. 1.5 throws many of our forum users into panic. 10 seconds is… really indicative of a major underlying problem. 60 seconds is obvious, but 10 seconds is really not acceptable.
I agree we are having to use a lot of weblog tags to accomplish what this homepage needs to accomplish. But we are on a powerful dedicated server. It may not be tuned 100% but is sure seems like the performance should be better then what we are seeing right now. We are not having any memory issues at all, just CPU issues and MySQL is the largest consumer.
Yes, we are caching templates (homepage, header, styles, javascript) and have our MySQL configs tuned well.
This morning I went through the home page template and directly added any content that didn’t need to be in an embed and also added an {if logged_in} clause around our inline edit button embeds (this accounts for most of the embed tags). These changes do not appear to have made any difference.
One problem that has been identified is a lot of MySQL temp tables are being created on disk. The host let us know last night that BLOB and TEXT columns are not allow in memory tables and so are written to disk. We have 180 fields set up in this install and 90 of those are TEXT type columns since that is the EE default. Last night I change most of the 90 columns to varchar with a set character limit specific to the content. That apparently should have dramatically cut down on the % of temp tables being created on disk but I’m not seeing that this morning.
Also, yesterday Mitchell from Solspace went through the home page template with me with template debugging turned on and did not see anything that dramatically concerned him. We did upload a revised File extension that makes less calls to the database.
All told, we made a ton of changes yesterday and this morning that should have made a noticeably different but I’m not seeing any:(
Well, what I would do now, if you were game, would be to create a template with just <p>Hello World</p> in it and see if that’s slow. Other processes on the server may slow this down, but you could certainly try it.
I would be that loads instantly. So then would try a very simple weblog entries tag, and slowly add to it until you find the block. Of course, if a plain template with some text in it takes 10 seconds to load (where other server processes aren’t affecting that) then we know its not your templates. =)
Also, here is a non ee php file
**This took 32 second to load for me
http://www.zocalo.com.mx/anna.php
This is strongly indicative of something server side, perhaps between MySQL and PHP. You’re getting these results outside of ExpressionEngine, so I would strongly recommend taking that information back to your host.
The first time very slow - so slow I kind of closed the tab. The second and third time 3-5 seconds.
Your PHP example is between 1 and 5 seconds depending on the refresh.
Your main EE template took about 5 seconds to start loading, and another 5-7 seconds to render all the graphics, scripts, and images (that is after EE delivers the data, so that maybe could use a look at too?)
So this seems like a fastish time of day for your site.
The website gets 40% of its traffic in a few hour window and that window is where we are having problems. Usually Monday-Wednesday mornings from 8-11 central time. Any time after or before, everything is okay on the site.
Well, we can tell a few things. A plain template (Hello World) loads very fast with lower loads. Your template does still load on the slow side (10ish seconds), part of which may at times be graphical rendering and the like.
So some of it could be some optimization in the templates, but it really does appear to be somewhat of a server related issue. I’d be very curious to see you load this on that VPS, and compare it to a totally clean installation of ExpressionEngine there, and see what we find out.
If it were me; I’d be loading a copy of your current site, as well as a fully clean install, into a development environment where no one would know the the troubleshooting that was going on. That would give you a nice clean comparison as well.
Since we have been focused on MySQL as the problem on the dedicated server, I did a test this morning…
I moved the database to one of the VPSs that we have set up. So nginx and PHP were on the dedicated server and MySQL was on VPS.
During my test, the CPU for MYSQL on the VPS was about 40% with normal spikes.
During my test, the CPU on the dedicated server came down to very normal numbers.
During my test, the website still failed to load pages within any reasonable time.
So I’m concluding that there is a problem at the server level that neither I nor the host has been able to track down.
As a final test before I move to another host, I’m requesting that this host set up another vanilla dedicated server running apache, php, mysql. I’ll move everything to that server hopefully this afternoon and will see what happens tomorrow am.
