A huge number of blogs use Feedburner to syndicate their RSS feeds. Since the service was launched in 2004, it’s pretty much become the de facto standard for this. With so many bloggers relying on Feedburner, reliability and performance is of course extremely important. RSS feeds, just like websites, need to be available all the time on the Web.
If you’ve been following the development of Feedburner, you’ll know that the company was bought by Google a while back, and as of late this February, Google is serving all Feedburner feeds on its own infrastructure. (If you’re curious about Feedburner’s old infrastructure, check out this article.)
Testing Feedburner’s RSS feed performance
We monitored the loading time and availability of the Feedburner RSS feed for our own blog:
Since Google presumably uses the same infrastructure for all Feedburner feeds, that should be indicative of the overall performance of Feedburner feeds in general.
The tests were performed once a minute with our uptime monitoring service, testing from locations in Europe and North America. (We’d like to point out that robots accessing Feedburner feeds don’t affect the subscriber count.)
Now that we’ve been monitoring the RSS feed for over two months, we thought it was a good time to have a look at the results and see how Google is handling Feedburner’s feed delivery performance so far.
Feed availability: Not bad but room for improvement
We started the monitoring in March (on the 9th, to be precise). Counting until now, May 12, the tested feed has been unavailable for a total of 53 minutes, resulting in 99.94% uptime (availability).
A 99.94% uptime means that the feed will be unavailable for 5 hours and 15 minutes over the course of a year. This is actually not bad, although considering the resources of Google, it can probably improve this number significantly.
Most of the problems appear to be short, temporary issues. The longest outage was a mere 13 minutes, the second-longest was 10 minutes, and the vast majority were around a minute (we detected 18 outages in total). The longer-lasting problems were due to severe slowdown (if we couldn’t load a feed in 30 seconds, we counted it as unavailable).
The shorter problems, or glitches if you like, were sometimes due to HTTP error 502 (bad gateway). The error message from Google when this happens is: “There was a problem retrieving the feed: Deadline exceeded retrieving from Bigtable.”
Bigtable is Google’s proprietary database system.
The resulting error page that you get instead of the feed looks like this (yellow emphasis added by us):
Other errors we detected were HTTP error 500 (internal server error) and as previously mentioned, timeouts. This is the resulting page from the 500 error:
Feed loading time: Gradually improving?
Over the period, the average loading time for the feed was 0.8 seconds. This is the average across all locations, both in Europe and North America.
As you can see in the below graph, Google seems to have gradually improved the overall performance of the Feedburner feed. When we started our tests in March the average load time for the feed was over a second on average, but after that performance has gotten better.
There was a period of significant slowdown the last couple of days in March, but after that performance has been relatively stable. Note that the values in the graph are averages counting over an entire day.
Unfortunately we don’t have any data on how the feed loading speed was on the old Feedburner infrastructure. It would have been interesting to compare.
Feedburner (now Google) has had its fair share of problems with the reporting part of its service, most recently at the beginning of April. However, here we only looked at being able to properly access and load the RSS feed itself (essential for feed readers). We have to say that Feedburner definitely gets a passing grade, although both uptime and performance has room for improvement. Google says it’s still working on improving Feedburner behind the scenes, so it will be interesting to see what happens in the coming months.
All monitoring in this survey was done with the Pingdom uptime monitoring service. For a feed to count as unavailable, it had to fail to load from two different locations.