Hosting a High Traffic WordPress Blog – GoDaddy Managed WordPress Review (Part 2)

This is a continuation from my post on how I wound up selecting GoDaddy as my first choice for a collegue’s high traffic wordpress blog.

First, I did hear back from GoDaddy on any traffic limits with the Managed WordPress platform.  There are no limits on any information that are served from cache, but for uncached information, they set a limit of 100 concurrent connections.  As I said in the previous post, 25 concurrent connections would be tough to saturate without a configuration error, so essentially there are no limits.  We’ll have to see how performance fares once the server is packed with accounts.  I’ll get to my performance observations later.

First, here’s some info about getting the WordPress site moved from wordpress.com to GoDaddy.  One of the selling points of the new Managed WordPress is that they can have your site set-up in a very short time – something like under 40 seconds if my memory serves me correctly.  The typical customer probably will arleady have their domain name registered at GoDaddy, but my collegue had his domain registered through WordPress.com.  We had to go through the wordpress.com account to change nameservers, but the domain was still not showing up.  It was very bizarre as it appeared that the nameserver settings had propagated, yet we still couldn’t see the new wordpress configuration.  I called support, and they said I had to change the DNS setting A entry to the specific IP address of the GoDaddy server.  Even with doing that, the site wasn’t showing up.  I emailed support and after another 24 hours, the site was finally live.  I don’t know GoDaddy support did something to complete the set-up or whether things hadn’t fully propagated.

Once things were working, we were able to login to the typical WordPress dashboard linked to from the GoDaddy dashboard.  Everything looked pretty standard with only two exceptions that I noticed fairly early.  The first is very minor, and that is a link at the top of the dashboard that says “Clear Cache”.  I understand what a Cache is, but I’m not sure your average wordpress user would know.  They use different layers of caching, which means storing certain content in a faster RAM so that it can be served to visitors faster and put less stress on their server.  It is a common way to improve performance of WordPress.  The second difference was more significant – under the Appearance link, there was no “editor” link, meaning you can not edit your themes directly in the WordPress dashboard.  There is now a work-around, which I’ll get to later so ultimately it isn’t a big deal.

I went through the typical process of importing the data from the wordpress.com site, installing the import plugin and getting it all set-up.  I forget the exact details, but it was easy to Google how to move your site and pretty straightforward.

As one of the reasons for moving to self-hosting was to monetize the website, I wanted to insert Adsense ads.  I used one of the common plug-ins I’ve used with other sites and everything seemed to be moving along okay.  The other basic plugins I used were All-in-one SEO, and Jetpack (for site stats).

I then came across another difference.  I usually install the “yet another related posts” plugin to show related posts after the content.  Next to the plugin, it says it is not available.  It turns out related post plugins use a lot of CPU resources, so they don’t allow it.  There are several other plug-ins they don’t allow, but none that I would have used.  Overall, this wasn’t a huge deal, and I appreciate that they are trying to protect the server performance by preventing plug-ins that will overburden the servers.

I then wanted to make some edits to the theme beyond what I could do with plugins.  This was a problem as FTP access was not initially available.  Around this same time, they were scheduling a Google “hangout” to discuss the product.  I figured I would see if there was some mention of this there.  I was actually able to block out some time to watch it, as I’ve never participated in a Google hangout before.  Unfortunately, there were technical  glitches that prevented them from getting it going.  I found it somewhat amusing that these technical guys at GoDaddy weren’t able to figure out how to do a Hangout, or that they didn’t at least test it out in advance to make sure they knew how to do it.  They did seem to figure it out about 30 minutes after the time it was called for and they ultimately rescheduled it for the next day.  I wasn’t able to take part the next day, but it was recorded and I was able to watch it later.

I noticed someone else has already done an excellent summary of details from that hangout.  I was impressed with the information they presented.  While much of it wasn’t that important to me, I was better able to understand what they are trying to accomplish.  It is an ambitious project as they are hoping to attract more basic users, yet they are also trying to optimize the product which can make the project much more complex.

The issues that were most important to me were their focus on speed and uptime.  They are using SSD to store information, which can be considerably faster than standard hard drives.  Also, they mentioned many layers of built in redundancy which is important for maintaining uptime and server responsiveness.  They also discussed caching, and trying to add additional caching in 2014.  Caching is important to have very fast loading times as well as being able to handle large spikes in traffic.  All of this information was good news to me and seemed to point out that the product would be a good fit for what we needed for our site.

I had emailed one of the hangout hosts asking to confirm that the design will be able to handle large spikes in traffic and to figure out if there was a workaround for editing the themes rather than having to make all of the changes locally and then upload via sFTP.

I was pleasantly surprised with a very thorough response to my questions and also the workaround to edit the themes.  Specifically, you can edit a line in the wp-config.php file:

define( ‘DISALLOW_FILE_EDIT’, true );

And you can change the true to false and then the link becomes available in the wordpress dashboard allowing you to edit your themes directly.  This saves me a lot of time, but it made complete sense why they got rid of that.  As the product was originally launched without FTP access, if someone messed up a formatting change in the theme, it is possibly to get blocked out of the site completely.  You would then need support to restore things for you to get back in.  At least with FTP access, you can fix your files or even just delete your specific theme folder to get things working again.

Interestingly, in his response, he checked out my collegues site and he said that there was a plug-in that was using php sessions, which was making the content not cache properly with their system.  With a few more emails back and forth, he was able to isolate the problem to the adsense plugin.  From teseting a few different ad placement plug-ins, it seems they all break the caching mechanism used by GoDaddy.  As I was now able to more easily edit my themes, I just hardcoded the Adsense code into the theme where I wanted it and was able to avoid using the plugin.

He also told me how to check to see if the site is able to be cached, by viewing the server response headers.  There are several ways to view these headers, but the easiest for me has been a website called web-sniffer.net (no longer available).  It shows the headers and there are two specific responses that will tell you if your site can be stored in cache: X-Cacheable, and X-Cache.  X-Cacheable tells you if the site is able to be stored in cache.  When I had the Adsense plugin active, the result was “No:Not Cacheable”, but once I removed the plugin, the response was “Yes:Forced”.  The X-Cache response was either “uncached” or “cached”.  They also have an “age” response which seems to be how many seconds ago the particular version was stored in cache.  As they have several different servers as part of their platform, it seems that a page may need to be loaded several times before it is reliably being served from cache.

I had set-up a pingdom monitor for the site to alert me to any downtime as well as give me a daily report of the average server response times.  Not surprisingly, the response time dropped from around 1000ms load times to around 550ms load times once it was being served from cache.

It is important to me that as many items are served from cache, not just for me but for all of the users.  Being in a shared hosting environment, if one or two sites are running poorly and have a high traffic demand, they can slow the system down tremendously.  I would guess that they have safeguards built into their system to prevent one site from hogging too many resources, but I do have to say I was surprised that the load times for uncached content was not faster, especially given the multiple server setup and using SSD for storage.  I’m assuming the system has relatively few users on it right now as it is only in beta testing and that they intend to load the servers up with many accounts.  Time will tell how the site will perform in the long run.

Once we had the site set-up to our satisfaction, we went ahead and had some traffic directed there.  Typical blog posts would get 10-15k visitors, but as the test post was done right around a holiday, the site only got around 3-4k visitors.  Traffic peaked at around 200 concurrent users based on Google Analytics Real Time (which is around a 5 minute sample), which is lower than we had hoped for.  Pingdom did not alert to any downtime and I was able to access the site during that time, so I’m assuming all was good on GoDaddy’s end.  We’ll have to see if the traffic numbers are better with a test after the holiday season is over.

I’ll get into optimizing the site for mobile viewers in another post, but I felt one thing relevant to this particular review was that I noticed when trying the wptouch plugin that it prevented the entire site from being able to be served from cache.  wptouch is a popular plugin and is nice for making sites mobile phone friendly.  I instead went with the built in jetpack mobile theme which seems to keep the caching for desktop and tablet user-agents intact.  Interestingly I noticed that when using web-sniffer as a mobile phone agent, the headers return that the site is not cacheable.  For my colleague, approximately 70% of the visitors are using mobile phones.  I’m not sure how significant it is that those visitors will not be getting served cached content.  Obviously the response times will be slower, but I’m just hoping that the set-up doesn’t lead to the servers getting overloaded if multiple sites have a lot of mobile traffic.  I’m assuming they either have or will be implementing some other form of caching for mobile phone users.  When I asked support about this, they responded saying certain plugins and themes respond dynamically based on user-agent.  They clarified that all static items are cached for all user-agents, including javascript, images, and css.  They also said they are working on solutions for plug-ins like WPTouch.

The above has been my experience so far.  I’m not sure if it is particularly helpful to anyone, but overall I have no complaints about the product and I am very optimistic for what it can become.  It seems they have smart people working on designing it and it is a perfect fit for what my colleague needs, assuming it lives up to the expectations.  It seems to me they are essentially trying to do what WP Engine does, but at a fraction of the price, especially for high volume sites like my colleague’s.

I have now posted part 3 of my review of GoDaddy’s managed wordpress hosting.