Our business offices will be closed on Monday, September 6 to observe the US Labor Day legal holiday. As always, we’ll provide same-day support for time-sensitive issues via our ticket and e-mail systems. However, questions that aren’t time-sensitive (including most billing matters) may not be answered until Tuesday, and telephone support (via callbacks) will be available only for urgent issues.
Many years ago, Microsoft’s “FrontPage” Web design software was a popular choice for creating small Web sites. However, Microsoft discontinued FrontPage in 2006, and you can’t buy the FrontPage program any more.
Quite a few of our customers are still using FrontPage to design and upload their Web sites, though. We’re starting to see more and more problems from customers who have upgraded to a new computer running Windows Vista or Windows 7 but can no longer run FrontPage. (Sometimes their old computer just suddenly crashes and can’t be recovered.) Their old computer probably had a copy of FrontPage installed by the manufacturer, but their new computer doesn’t.
It can be difficult or impossible to get FrontPage running on a new PC if you can’t find the original installation CDs, or you aren’t licensed to use FrontPage on the new PC. In some cases, the old FrontPage software doesn’t install or work well on the latest versions of Windows. In these situations, you can’t even open the old FrontPage files on the new computer.
Three of our Web hosting servers (amy, flexo, and leela) experienced high load earlier today that caused some customers to see “503 errors” on their Web sites for a few minutes.
This was caused by an upgrade to the eAccelerator PHP caching system that removed all the cached files at once, which doesn’t normally happen.
The problem has been permanently resolved and will not recur.
Between 10:00 PM and 11:59 PM Pacific time this Saturday, August 28, 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”.
WordPress installations handle missing image files very inefficiently by default, running the entire WordPress script to build a custom “404 Page Not Found” page rather than simply letting Apache return an immediate default “404” response. Running the WordPress script when not necessary is a huge waste of processor time. For example, WordPress might be able to only process 8 requests per second for a missing image when WordPress generates a custom “404” page, but Apache can return process over 1,000 raw “404” responses per second. If your Web site contains references to missing files, this default WordPress behavior can be driving up your CPU usage unnecessarily. We’ve seen poorly-configured Web sites spend a significant portion of their CPU time processing missing images.
The WordPress folks recently announced that next year’s planned WordPress 3.2 will require at least PHP version 5.2 and MySQL database version 5.0.15. If you use WordPress, you might be wondering if this will be a problem.
Well, “Good news, everyone!” If you use Tiger Technologies to host your WordPress blog, you’re all set: we already use later versions of PHP and MySQL than that.
Our monitoring systems are showing that some people who reach our servers via an “Internet backbone” company called Global Crossing, including some Comcast cable customers, have been intermittently unable to connect over the last hour or so.
This isn’t an outage on our end; these visitors are also unable to reach other sites that Comcast routes through Global Crossing (and not related to us), such as www.globalcrossing.com. It’s something Comcast and Global Crossing need to address.
We’ll continue to monitor this issue closely and post an update when we’re confident that it’s been resolved.
By the way, if you ever find that you’re unable to connect to our servers (or anyone else’s), a very useful site is CheckSite.us. It shows you whether the destination servers are down, or whether the problem is just a local routing problem that isn’t affecting most other people.
Update 9 AM PDT August 13: According to our monitoring systems, Comcast resolved this shortly after our post, and the problem has not recurred in the ten hours since then.
Google FeedBurner is still hammering several of our customer sites with over 5,000 requests for the same URL per hour. We’ve blogged about this before. We’ve also reported it on the FeedBurner Help Group and seen similar reports from others going back to 2008.
Here’s the relevant log entries from a site that FeedBurner hit 5,836 times in one hour this morning (up to 8 times a second). There’s nothing unusual about the site: it’s on a single IP address with a single hostname, and the feed doesn’t change often.
Some sites run a PHP script for every request, so this FeedBurner problem generates high load for no useful purpose at all.
Google: Please fix this. Thanks!
One of the tools we offer our customers is the “wget” program, which can be used to fetch files from other Web or FTP servers.
It turns out that wget has a security bug that needs to be avoided. As a result, the behavior of wget has changed in some situations. If you use wget (most of our customers don’t), you should be aware of this change.
Between 11:00 PM and 11:59 PM Pacific time tonight (Monday August 2), several of our hosting servers will be restarted: bender, elzar, farnsworth, lrrr, mom, and seymour.
As a result, Web site service and the ability to read incoming e-mail for some customers will be unavailable for approximately five minutes at some point during this maintenance “window”.
