We’ve got a lot of customers running WordPress, and we definitely recommend running WP Super Cache to improve performance. It can help dramatically!
But recently we’ve seen a number of our customers getting hammered by a ton of requests from FeedBurner. Usually the request is of this form:
/somepost?utm_source=feedburner&utm_medium=feed&utm_campaign=SomeCampaignString
We’ve also seen FeedBurner going crazy and making thousands of duplicate requests. One of the sites we host has gotten 45,000 simple status requests (HTTP “HEAD” requests) from FeedBurner today, for no good reason that we can see.
Read the rest of this entry »
Many Web sites write data to a database. Usually, the data absolutely must be properly saved, so the default way of adding records (using an SQL “INSERT” statement) ensures that the data is permanently stored on the server’s disks. Doing that takes a relatively long time in computer terms — it’s much slower than most things computers do.
In some cases, you might be storing data that’s not quite so important. And if it means your application can run much faster, you might be willing to risk a very small chance of data loss. That’s where MySQL’s “INSERT DELAYED” statement, which works with MyISAM table types (but not InnoDB tables), can be useful. (Tables are created as type MyISAM by default, so most tables are eligible to benefit from this tip.)
Read the rest of this entry »
We’ve finished upgrading our network so that all of our customer Web hosting and mail servers have full, direct gigabit links to Internet peering points, with no 100 megabit Ethernet segments anywhere. This involved replacing old Ethernet switches and retiring old servers, and now we’re more than ready for the future.
Read the rest of this entry »
If you use the WP Super Cache WordPress plugin (and you should, if you use WordPress), it has a settings page section titled “Expiry Time & Garbage Collection”. It sets the “Cache Timeout” to 3600 seconds by default, and warns that you should set it lower on a busy site.
That advice makes sense if you have a sudden surge of traffic to a single page. However, if your site is generally very busy across all pages (for example, if you have an archive of hundreds or thousands of posts that are constantly being indexed by search engines), we’ve found that you should do the opposite to improve performance: set it much higher. We recommend setting it to 172800 seconds (which is 48 hours). This can cut your CPU usage in half, which will speed up your site.
Read the rest of this entry »
On Friday, a problem made our “My Account” control panel system unavailable for about three hours, and caused some other problems as well. We promised we’d follow up with more details.
Read the rest of this entry »
At approximately 10:00 PM Pacific time tonight, January 16, the “amy” Web server will be restarted.
As a result, for customers on the “amy” server (only), Web site service and the ability to read incoming e-mail will be unavailable for approximately five minutes. Customers on other servers will not be affected.
Read the rest of this entry »
Starting at about 1:30 PM (Pacific time) today, some of our internal database systems had an unexpected failure. This lead to problems with our control panel (“My Account”), support site, and blog. Some customers may have also had problems with some aspects of Webmail (in particular, with the address book).
No customer data or Web sites were affected, and no e-mail was lost.
All systems are running again, so no one should see any problems — please let us know if you do! Some things are running on backup systems, so we’re working on finishing up the fixes and restoring everything to its normal status.
This was an unplanned and fairly horrible (and embarrassing) problem. This is the first time our own account management database has completely failed in the 10 years we’ve been providing Web hosting service. Obviously, we consider this sort of thing to be unacceptable, and we sincerely apologize for any inconvenience caused.
Read the rest of this entry »
One of the features of our e-mail system is that we add SpamAssassin headers to incoming mail that isn’t whitelisted, as described on our SpamAssassin page.
A bug in the SpamAssassin software caused SpamAssassin scores to be incorrectly calculated for the first few days of this year: the scores were higher than they should have been.
We don’t use SpamAssassin scores as part of our spam filtering system, so this doesn’t affect most of our customers at all. However, some customers may have added custom rules to their mail programs that examine the SpamAssassin headers. If you do that, and you’ve directed high-scoring messages into a spam folder in your mail program that you don’t usually look at, you should look at all messages received between January 1 and the morning of January 6 to verify that they are actually spam.
Just so it’s clear, this bug affected everyone using SpamAssassin with any ISP or hosting company, not just our customers. That said, this bug unfortunately persisted on some of our servers for longer than it should have done, due to a technical issue with the way Debian Linux distributes SpamAssassin updates. We apologize for any problems this caused our customers; the problem was resolved on all servers early today.
Between 10:00 PM and 11:59 PM Pacific time this Sunday January 3, all our hosting servers will be restarted. As a result, Web site service and the ability to read incoming e-mail will be unavailable for approximately five minutes at some point during this maintenance “window”.
Read the rest of this entry »
