Tag: gzip

Bluehost drops support of Gzip compression

Last week, Bluehost sent this notification:

SERVER PERFORMANCE UPGRADE

Dear DOUGLAS,

We’re pleased to inform you that the server hosting your dograt.com website will be undergoing a major software upgrade, from CentOS 5 to CentOS 6, within the next 48 hours.

This upgrade includes newer software packages (including Python, Perl and gcc), as well as all the security and performance benefits that come along with CentOS 6. In addition to this, the server will be redeployed with a different file system type simultaneously, further increasing performance.

Although a bulk of the upgrades to your server are being done with it online and functional, in order to safely finalize these changes our Administrators will need to temporarily take your server offline in the early morning hours. Barring any extenuating circumstances this outage should only last about 2 hours.

Please note that while we do not anticipate your software having problems post-update, it may be required to re-compile any module(s) you are using to take advantage of the newer included libraries. We suggest reviewing your site afterward to verify that it is functioning as it should.

The case can be made that the upgrade actually reduced performance, because after the update was run I saw that Gzip compression wasn’t working. In the cPanel manager for my Bluehost Pro account the Optimize Website option is gone, and that means something called “mod_deflate” in the Apache Web server is no longer supported. So I wrote to Bluehost and here is their reply:

I’m sorry to inform you but we did away with that icon as it caused problems with other things in the hosting account, this was done fairly recently and wont be coming back in the near future or ever that I am aware of.

First they were pleased to inform me, then they were sorry to inform me. From this I am inferring the real issue is that CPU power is more expensive than Internet bandwidth. The loss of Gzip means that every character of text in this post and the page it’s on is being sent, rather than going across the Internet in a compressed format that uses about one quarter the amount of data, before being unpacked by a browser. If I want Gzip compression, I’ll have to force it in PHP, then see if Bluehost’s dreaded CPU throttling returns for the first time since upgrading to their Pro plan.

Zip-a-dee Doo-Dah

This will be a boring post about a technical aspect of blogging, called HTML output compression. I’m going to tag it so that anybody else who is wondering about the same thing I was a few days ago might find it.

There’s a site called Is My Blog Working?. A little while ago I plugged in the Dograt URL and saw this.

A couple of minutes later I refreshed the information and saw this.

The difference between these two views is the loss of Gzip compression. Newer Web browsers support compressed HTML pages. This can greatly reduce the amount of data that’s sent over the Net for a Web page. There’s no point in trying to compress something that’s already compressed, like JPEG images, but anybody who’s ever turned a text file into a ZIP file knows it’s like Wonder® bread — it squeezes down to a fifth or less of its original size.

WordPress is written in a scripting language called PHP. It’s possible to have compression done within PHP, and some WordPress sites do this, but it increases the processor load for the site. Bluehost, which this site runs on, temporarily throttles back individual sites that are using a lot of processor time. Dograt.com currently shares a Web server with nearly 3,000 other sites(!), and enabling compression in PHP would invite a big spike in my site’s throttling, that is otherwise lessened by the use of a WordPress plug-in called Quick Cache, which holds onto pages that have already been viewed, so they don’t have to be created again the next time somebody asks for them.

Other WordPress caching plug-ins can enable compression in PHP, but I don’t use them because the best place for compression to be done is below PHP, in the Web server program. For many blogs, including mine, that Web server is an open-source program called Apache. Enabling PHP compression when Web server compression is already working, and attempting to compress data that’s already been compressed, slows things down and accomplishes nothing, which is why WordPress doesn’t offer PHP compression as a standard feature.

Enabling compression in Apache for a site requires an entry in the site’s Hypertext Access File, .htaccess. This can be done manually, by editing the file, or through the control panel software. In cPanel the compression feature is found under Optimize Website.

So this begs the question, why is compression not always — in fact, it’s rarely — enabled for this site? It’s because Bluehost turns off Apache’s compression feature when the CPU gets too busy, as explained by Bluehost’s founder, Matt Heaton.

http://www.mattheaton.com/?p=228

We then wrote a patch to the Apache web server (This is what serves your websites to your browser) that interfaces with our CPU protection system. This patch checks our CPU usage twice a second and if CPU usage exceeds a certain threshold then we temporarily suspend mod_deflate. When there are unused CPU cycles then it reenables mod_deflate. By implementing it this way we get all the benefits of mod_deflate with none of the detriments of excessive cpu usage causing slowdowns.

Bluehost is vastly faster, more stable, and reliable than iPower, the hosting service I was using until two years ago. Oh, there are occasional blips, like cPanel wasn’t working briefly a couple of weeks ago, and every so often the site has been offline, but for the money I’m paying I’m pleased with Bluehost.