Serving the Raspberry Pi 3 launch from a Raspberry Pi 3

On 29 February this year, we launched our newest computer, Raspberry Pi 3. Launch days see a rather large amount of traffic to our website, and as a newly released product, Pi 3 was a relatively untested hosting platform. So naturally our hosts at Mythic Beasts decided this would be the perfect occasion to try serving some of the site from a Pi 3 itself. Here’s Pete Stevens from Mythic to explain tell us how it went: over to you, Pete!

It’s no secret that Eben Upton would like to make Raspberry Pi the standard computing platform. Periodically the question comes up – can we replace our $10,000 servers with a $35 credit-card computer? Up until now the answer has always been no: not enough IO, memory etc.

Initial Pi 2 testing suggested that in some circumstances it’s a reasonable web server. Pi 3 brings a welcome speed bump, and the recently released PHP 7 makes WordPress run much more quickly. To answer the question definitively we needed to find a high-traffic WordPress site and try it out. So we asked Liz Upton if we could host some of the Raspberry Pi 3 launch website on a Pi 3. A relatively untested platform, a modified software stack, and the highest profile and highest traffic day to announce it publicly – what could possibly go wrong?

The production setup

Diagram of the load balancers and back end hosts for the blog. We have more load balancers than back ends to cope with operating system downloads and package updates

Diagram of the load balancers and back end hosts for the blog. We have more load balancers than back ends to cope with operating system downloads and package updates

Raspberry Pi now has a fairly complicated back-end setup, using lots of virtual machines and an IPv6-only network to split the site into multiple administrative domains whilst keeping up with the performance and bandwidth demands of all the people who visit it. Above is a simplified picture of the setup, covering only the blog and front-ends.

About 5% of requests were diverted to the Pi 3, and 3% to the Pi 2.

Configuring the Pi 3

The Pi setup is fairly straightforward. We took an 8GB SD card to put the operating system on, and a 32GB USB flash drive to hold the data for the blog. /var/www comes to about 17GB, so there’s plenty of free space. We installed Raspbian Lite with the minimal set of packages to get the web server up and running. We then added the Debian stretch repository and installed the armhf PHP 7 packages.

We set up our IPv6 address so we had networking, and added our Pis into the load balancers to take a small fraction of the traffic. We did this several days before the launch to test that everything seemed to work, and under normal usage nobody noticed. Briefly, we turned the Pis up to taking 25% of a typical day’s traffic; everything continued to work swimmingly.

We added HTTP headers to indicate which host a request is served from. If you have a Linux machine handy (and if you don’t, you can buy a Raspberry Pi 3) then you can see this with:

$ HEAD -e
X-Served-By: Blog VM 1

HEAD sends a request to the web server, and -e means print out all of the headers. Occasionally you’ll see that header become:

X-Served-By: Raspberry Pi 3

which means your request came directly from the Raspberry Pi 3 in the data centre.

Rasberry Pi 3

Our Raspberry Pi 3 next to a Raspberry Pi 2 serving requests for the Raspberry Pi 3 launch.

The Launch

At 7am on the 29th of February, the announcement went out on the Raspberry Pi blog and our traffic picked up. This is the traffic graph from the switch for the Pi 3 on launch day.

Network traffic from the Pi 3 on launch day.

Network traffic from the Pi 3 on launch day.

The load balancers kept the response rate fairly constant to maintain a snappy response for all visitors to the site. Looking at the logs, around 5% of all requests went to the Pi 3.

Unfortunately, after nearly 12 hours and 1.5 million requests, our Pi 3 fell over with a kernel panic. As expected, the load balancer re-routed all the traffic to the main VMs, leaving virtually no impact apart from a handful of people whose requests were in progress at the time. We investigated what had happened, and found that the Pi 3 had managed to run out of memory and be driven into swap.  The flash card had then corrupted itself, which caused the Pi to crash. It came back cleanly on reboot – the Pi itself was completely unharmed.


We gave our Pi 3 a Twitter account and a small script written in Perl so it could send tweets. Once we’d installed IO::Socket::INET6 so that Perl had full IPv6 support, Net::Twitter was able to send posts to Twitter even though our Pi 3 was on an IPv6-only network and Twitter is still IPv4-only. Our NAT64 service provided translation, and throughout the day our Pi 3 was able to report its status on Twitter.

So is it any good as a server?

For some tasks, yes! It’s cheap and quite fast. If you need inexpensive processor cycles and not much IO, or you require a very inexpensive dedicated server, it has a lot of merit; and for some security-sensitive or latency-sensitive applications, dedicated hardware is a must. Pair it with an encrypted filesystem on an SSD, and you’ve easily got a very secure VPN server.  A cluster of ten provides a lot of processing power very cheaply.