Thread

I just recently bought myself a copy of EE, mostly for fun and learning, and one of the first things I noticed is poor performance when hosted on my GoDaddy account.
Initially, when the site hasn’t been touched for some hours the performance is extremely poor, but that’s pretty much standard for shared hosting, byt after a while performance goes up - but not at all to the levels I’m used to with for instance Wordpress or vBulletin (on the same hosting account)
Does EE hammer the database more than normal, or would there be other issues to “fix”?

I have a site I’m working with a tutorial on hvid.nu where there’s not more than navigation between home and about working, and the load time would be more than 3sec when switching. Also the CP has these 3-5sec delays for every change of page.

Would this be normal behavior for a relatively small site like this?

Best Regards
/patrick

Welcome to the ExpressionEngine forums, PaHvid.

Since you’re new to the EE forums, have you seen EEWiki:// How to Post a Support Request?

While you can run ExpressionEngine on GoDaddy, it can be painfully slow. For a few dollars more a month, I’d recommend switching to a different provider.

I normally suggest EngineHosting at this point, since I’ve been working with then since around 2003, and they are optimized to work with EE.

Other community members may have other suggestions..

Thanks Sue for your answer

Since GoDaddy (to my utterly surprise) delivers the best performance of my tested providers (so far) on non-database intensive applications like WP I guess that’s where the hang-up is.

I’ll consider other solutions when, and if i go public with anything. At the moment it’s all about learning and playing 😊

/patrick

patrick, what Sue says here is basically an appropriate reply, with regard to GoDaddy, and EngineHosting as well I would recommend, as they offer a shared hosting which is actually managed to give consistently decent performance, for USD 10/mo.

Here are a couple of tips that will help on GoDaddy, until or unless that hoster lets your shared server become unusable, as they did one I had there (lots of support conversation, very little result).

- be sure you are setting your templates to use Template Caching, with a reasonable interval, for example 3600. You can set this on the template’s Preferences, or for a batch of templates at a time via the Template Manager’s Template Preferences Manager (button). This will make a lot of difference after the first time or two a template’s called, until the cache time runs out; and it’s not defaulted to On in EE.

- be sure you have Persistent Connections set to No, on the Admin>System Administration>Database Settings. This may seem counter-intuitive, but in fact it’s necessary for decent performance on many sites due to shared database servers, and on GoDaddy it is critical - persistent connections will give very bad service at high load times.

- SQL Query Caching on the same Database Settings page can possibly be of some use, in some cases; but at present I believe it’s defaulted off and actually not functioning internally, until an issue is settled for a later EE release.

[edit: I noticed EE documentation is now recommending against this also when there are certain forms of database arrangements, and I have seen what they are concerned with, so also SQL Query Caching will be a set-and-test usage in future, with tests done carefully across heavy as well as light host load times, to see what an individual situation really benefits from. Nothing for free in this life 😉 ]

Hope this helps, patrick. It did give me quite decent performance at GoDaddy for a while, outside of the load-moment slowdowns you get on most shared hosting. I think any of the low-price shared hostings are pretty grim, actually, and that EngineHosting at least in my experience has shown to be a consistently good bargain.

Regards,
Clive

Thanks narration for extremely useful tips!

I will try them out tomorrow, and actually revert some changes (persistent database connection) that I have wrongfully set 😊
If it doesn’t help to give adequate performance for a public site I’ll consider moving when that might happen.
For now I’m happy to have all sites, domain hosting etc in one place.

I’m NOT arguing that GoDaddy should be a better choice than EngineHosting at all, on the contrary, I was surprised that the performed so well on my normal sites, and that was the reason for choosing them. Also I live in Sweden which have other data centers than the US based, so perhaps the load is lower here, and therefore the don’t live up to their “poor reputation”  😊

patrick, very good—and yes, I used to operate US hosting from Switzerland, so understand your observations. Also a quite good Swiss hoster from the US.

This is actually a complicated topic indeed, and I can tell you that a high-end corporate solution will often use special content delivery networks like Akamai, or even more complex solutions, to get those ‘instant page’ result. Very expensive, and I suspect that as they become more sophisticated, the mesh hosting solutions will begin to include something like the same results.

In any case, for private or smaller scale, the more intricate solutions aren’t what we use. What is quite important then is the kinds of connectivity the hoster has—whether it is ‘close’ in internet terms to the giant feeds, with no bottlenecks. And because of the way the Internet works also, much more complicated than it seems, effective hosters have to be ‘close’ to several of those feeds.

I think EngineHosting looks good this way, and maybe GoDaddy isn’t actually so bad, hence your reasonably good first results. I had those results too, at first, and being able to handle GoDaddy’s technical issues, which they do have pretty good information about while insisting that you self-support. But then it was the management of the shared servers that broke down. I think they may put new customers on newer servers, which then fill up….

But let’s not borrow trouble. I got along for a year or so before issues became unmistakable, and you can go with your own situation for as long as it works for you.

The switchover then, in the experience with EngineHosting, was very smooth. They gave a temporary URL to work with as I brought the EE site over and tested it—then we switched the DNS, as always must be done, and the new site information had ‘propagated’, taken over anywhere in the world, in a few hours, with no down time visible to a visitor.

Good fortune, patrick, and nice to see you are working from Sweden. I am listening to Göteburg’s Downtown Ramblers when I want to find a certain kind of good mood 😉.

Regards,
Clive

Thanks for the assist, Clive. All good pointers to working within GoDaddy.

Patrick, is this enough information for this particular thread? Or is there anything else we can assist you with?

On a related note…

Running on 1.7.0

For some reason individual post pages load times have started to increase significantly.

No real major changes to the site.
Control panel side is still zippy.

Example Page
http://www.drummagazine.com/lessons/post/cindy-blackman-playing-the-breaks/

Pingdom
http://tools.pingdom.com/fpt/?url=http://www.drummagazine.com/lessons/post/cindy-blackman-playing-the-breaks//&id=4334015

Hoping that it’s something boneheaded that I’m not seeing… and yes I know that background image is huuuuge. 😛 On the to do list.

Thank you.

Well, yes, you do have something going on, from the look of things.

First, let’s deal with that huge image. You’re using a PNG, which gives you great image quality for the drum, which I presume you like.  The PNG has transparency, which isn’t being used as far as I can see. This means that you can replace it with even a high quality JPG, and still reduce the size (and time to load that image) by something like a factor of ten. Converting to a JPG at 85 quality, I am not sure I can see any difference at all in quality, and the size is 91K, rather than 813K.

Even so, that image is not your primary problem, though it will be a standout for a visitor with a slow connection.

Your site actually runs ExpressionEngine with quite reasonable speed—try http://www.drummagazine.com/lessons/, which is nice and snappy. However, when you click on a specific post, as listed on this lessons page, you get a very long page processing time - over 10 seconds before the first return begins from the server, as Pingdom shows.

What I would do is log in on another tab to your CP, and turn on Display Output Profiling and Display Template Debugging on Admin>System Adminstration>Content and Debugging—be sure to Submit.

Now, when you reload your page on its own tab in the same browser, you’ll see a long set of extra information below the page. You might get a clue from the SQL query timings if there’s a database issue, or from the template processing step timings nearer the bottom if it’s a template code or add-on issue.

Similarly to the case of the image, I think you should be running over ten times as fast as you are for that post page—and considerably better yet with caching in place, with processing taking just a few tenths of a second or so.

Just as a tip also, it’s good to keep in mind that Pingdom always shows your worst case, downloading every detail as if a browser’s cache were empty each time. With a big delay on the primary page return as at present, though, that’s going to dominate the browser speed so that you don’t see the benefits of its caching.

Good fortune, and am sure we’re all interested what you find.

Regards,
Clive

Thanks for the suggestion!

WIll report back any findings.

Thank you.

Well. The roadblock seems to be Solspace’s Tag module.

Removed the reference in the templates and things fly now.

Now will need to try to figure out how to get the module to work properly.

Thanks for the help!

Sounds great, creativesherpa, and glad you could home in on this.

I run Solspace Tag also, and haven’t had performance issues with it being on a page.

They’ve had a number of upgrade versions for Tag, to keep up with needs of EE releases, and quite possibly this is where you’re getting the issue.

I would imagine the latest Tag version would be fine.

What you need to be very sure to do, besides replacing everything within the system area that they give you, which is a lot, is to also replace their themes with the upgrades they give you, in your site root themes folder. That’s kind of critical.

Also, the Solspace website makes it a bit hard to know how you are going to download your upgrade. The secret is to log in to the site first. Then go to the product page for Tag. A block with a download link will have been magically added, and that’s what you use.

That’s what I get, scratching around in the memory cupboard. Time for dinner 😉

Regards,
Clive

@Clive and all…

You are 2 for 2. I was running Tag 2.x and upgraded to Tag 3.x.

It has resolved most of the issues. The remaining issue is because of some spaghetti logic code that just needs to be simplified.

Thank you!!!

will need to put a flag on my task manager to check in with Solspace more often 😛

Glad to hear it. Had a peek, and looking good - should be quite good once you have a chance to replace that background png.

It’s a nice looking site - kind of enjoyed it as have been a musician.

Regards,
Clive

Glad to hear it. Had a peek, and looking good - should be quite good once you have a chance to replace that background png.

It’s a nice looking site - kind of enjoyed it as have been a musician.

Regards,
Clive

Thank you. It’s been a steady stream of improvements but many many more still left on the growing to-do list.

oh.. and even if you don’t play now you’re still a musician 😉