Yesterday, we “upgraded” the four older servers to remove PHP 4.X track from your available options. As it’s getting close to the PHP4 End of Life moment (2008-08-08 is D-Day for PHP4) we wanted to go ahead and make the jump now as both versions have been running for almost a full year. We also took the time to upgrade PHP to 5.2.6, as well as compile mysqli as an option. Everything went well and it appears most of you have made the jump to PHP5.X, as there was no mad rush to the ticket desk.

We also wanted to let you know that there are two new staff members covering the tickets, and if you’ve submitted one within the past few weeks you may have met them. Thomas Williams, and Brian Hochstein have joined the team - they both have some familiarity with hosting, and while Thomas is familiar with hosting in general Brian’s pretty familiar with DrakNet as a whole, so give them some time to get up to speed and if you feel you need to have your ticket upped, please don’t hesitate to ask politely. As always, abuse of our staff is just not tolerated here - we’re geeky tech hippies and too laid back to smile while people call us names, so give them some slack while they’re learning about ya’lls quirks.

You’ve got a few weeks left to get yourself on the MySQL 5 server with some leeway time, as in mid-July we’re upgrading all servers to MySQL 5. We’ve had very few requests for this, so we’ll warn you now we’re not going to have an immense amount of sympathy if your stuff is not compatible with the current recommended version of MySQL. We can get you moved over in a few minutes while maintaining your old installation so if you need to take advantage, do so, and soon.

We should get back to our snarky banter posts soon.

Some discussion has started in the cPanel forum (where hosts come to compare notes on those non-documented features of cPanel and other software) regarding the latest Wordpress upgrade (2.5), and its new resource-hungry attitude towards CPU and memory.

For most blogs, this won’t be an issue - for popular blogs that are nearly continually visited, this may begin to be a bit of an issue in terms of hosting cost (if you average out at higher resource usage, you may be required to upgrade) and the dreaded “Digg Effect” preparation that is well known to take down sites on shared hosts (along with everyone else on the server with them) - which is both good, in the fact everyone loved you, and bad, in that half the Internet shows up on your door at once.

Since you, obviously, want your blog to be bigger and heavily trafficked, it’s a good idea to prepare for those eventualities before half the Internet shows up at your front door, and one of the ways to do that is to install the WP Super Cache plugin.

WP Super Cache is a static caching plugin for WordPress. It generates html files that are served directly by Apache without processing comparatively heavy PHP scripts. By using this plugin you will speed up your WordPress blog significantly.

This plugin is a fork of the excellent WP-Cache 2 by Ricardo Galli Granada. WP-Cache 2 caches the pages of your WordPress blog and delivers them without accessing the database. Unfortunately it still means loading the PHP engine to serve the cached files.

WP Super Cache gets around that. When it is installed, html files are generated and they are served without ever invoking a single line of PHP. How fast can your site serve graphic files? That’s (almost) as fast it will be able to serve these cached files. If your site is struggling to cope with the daily number of visitors, or if your site appears on Digg.com, Slashdot or any other popular site then this plugin is for you.

If you’re starting to become popular and are getting worried, are popular and are already worried, or hope to become popular and don’t want to be worried, we suggest that you check it out. There are some pluses and minuses to installing it so make sure to read the page thoroughly.

And one more tip - if you do ever find yourself dugg or slashdotted, one of the quickest ways that you can speed up your site if to turn off, temporarily, mod-security.

mod_security supplies an array of request filtering and other security features to the Apache HTTP Server. What that means in practicality is that every single request that comes in through httpd (the web server) is compared to hundreds of known signatures of attacks and if it matches those, the request is not allowed to be completed. This application firewall works in tangent with out firewall in stopping known compromises on software programs. It’s drawback is that instead of simply getting a request and serving it, apache has to process each and every request and compare each one to those hundreds of signatures before letting it through. An unexpected major, massive spike in traffic (the digg effect) can dramatically pile up those requests because there’s more involved in processing them.

You have the ability to turn off this security for your site - during general, day to day operations, this is not recommended. During a Digg, though, it’s almost required and may be the difference between keeping your site online and slowing the server to a crawl.

You can temporarily disable mod-security by adding a specific command in the .htaccess file. Locate the .htaccess file in Apache web root directory (public_html), if it does not exist, create a new file named .htaccess, and add in the following code:


SecFilterEngine Off
SecFilterScanPOST Off


The above entries in the .htaccess will disable the ModSecurity (mod_security) module for the domain. Once the spike in traffic has passed (with Digg specifically, it seems to be about two days), simply remove the lines from your .htaccess, or remove the .htaccess itself if this is all that’s in it.