I'm the sole developer and maintainer of raspberrypi.org - we're a small team at the Foundation and I do this alongside outreach, educational resources, teacher training, software development and other projects. We pay Mythic Beasts for a basic hosting service and they kindly provide us with a full support service in running the server and keeping the site and other services on the machine alive. That one machine runs various Raspberry Pi sub-sites, the Raspbian and NOOBS downloads server, the Raspbian apt mirror, MPEG licence key generation and more.<p>1. Why PHP?<p>We all know PHP sucks (we advocate Python in education), but WordPress is ideal for authors and contributors and that's what we had to begin with.<p>2. Why WordPress?<p>When I joined the Foundation in 2013 they had a WordPress site Eben set up in 2011 and I wanted to keep the great user experience WordPress provides to authors and contributors so I built a bespoke theme expanding the content beyond the simple blog, keeping all former URLs working despite changes to the URL structure. Some of the newer content, like documentation and learning resources, is outside of WordPress and is pulled in from github and rendered into templates.<p>3. But why not build your own bespoke framework?<p>Firstly, if I did that, you'd tell me perfectly good web frameworks already exist. Secondly, WordPress is very mature and it's easy to add functionality quickly. I'm not talking about BS plugins - I hardly use any. I mean it's easy to add stuff into the templates, stuff you're likely to want to do. Finally, I'd rather spend my time and the Foundation's money doing educational projects.<p>4. WordPress caching plugins exist. Why don't you just use them?<p>We use WP Super Cache. It does most of what we want, but has some pretty fatal flaws: it doesn't go to cache for "logged in users" (including anyone who's ever made a comment), it recreates the cache after every comment, it does some work to figure out of it can give the user a cached page or not (this slows it down a lot), it doesn't cache the 404 page (more important than you'd think) and it doesn't cache requests with any GET methods params. Mythic created their own static page generating script for the pages with the most hits which updates every minute, and that's what kept us alive this time.<p>5. Why not use NGINX?<p>See a full article on this here: <a href="http://blog.mythic-beasts.com/2014/11/14/hiphop-and-wordpress-if-youre-tired-of-tea-then-youre-tired-of-life/" rel="nofollow">http://blog.mythic-beasts.com/2014/11/14/hiphop-and-wordpres...</a><p>6. What about hiphop vm?<p>We tried it. Fast but unreliable. We saw a huge rise in performance but most of that came from the upgrade from Wheezy's PHP 5.3. Compared to Jessie's PHP 5.6 was less impressive.
I want to criticize the choice of headline here, which was no doubt the point of having it. It's not about PHP. PHP runs fine on Pis. Not that I would ever advocate running a website with serious traffic on that device, but it could very well serve a 50-100 dynamic requests per second (I just tested this with my Pi B running NginX and my custom home automation software which is web-based, the baseline is 250 static small file requests per second, so not a great starting point for publicly hosting things).<p>Instead, this should be a critique of Wordpress, which is like almost any other successful software immensely bloated. There is nothing inherent in PHP promoting this verbosity. And even if you are dealing with large code bases, PHP's request-based execution model gives you good tools to just execute the codepaths you need. But in practice, little consideration goes into minimizing execution bloat and overhead. Of course there are reasons why WP is bloated, some of them bad, some good, some subject to debate. Caching and avoiding dynamic code execution will be a big part of optimizing any Wordpress install for the foreseeable future.<p>We're moving towards more bloat, not less. The best practices of many programming environments actively encourage us to disregard cycles and latencies. This happens in PHP, in Node, even in C++ frameworks.
One form of this article might be: "Here are some best practices for hosting a high-traffic WordPress site."<p>Another form is "I saved the world from a trillion lines of PHP! And if we did this on AWS it would be <i>many tens of thousands of dollars per month</i>..."<p>Perhaps I should make sure I'm giving the author the benefit of the doubt:<p>"... you’d still need to make sure you can effortlessly scale to thousands of cores ..."<p>10k users peak. <i>Thousands</i> of cores? $30k+ a month? This is blatant misinformation.
Reading the article they finally get down to what it is...98 lines of perl that serve as a url specific content cache.<p>A somewhat odd solution for a php driven website. Since you're in php already, a more typical solution would be to use apcu to have the cache in shared memory.<p>Or, if your needs are more complex, using an already established cache like the one in nginx or varnish, etc.<p>Whatever they did served their needs, but I'm not clear on why "we made a one-off url+param keyed cache" rates an article.
I was one of the original raspberrypi.org trolls for a couple of months. RS Components scammed me with a "preorded" and kept moving delivery date for HALF A YEAR, while at the same time __already delivering__ to newer customers - they prioritised fresh customers over me, because they already had my money :/<p>Similar thing happened again with Zero, all big fat distributors (this includes Adafruit) engaged in scamming early customers by bundling $5 product with $2 of cables and upselling whole thing as a $20-60 pack(!!). They went as far as removing $5 product listing altogether. <a href="http://www.adafruit.com/pizero" rel="nofollow">http://www.adafruit.com/pizero</a> had $5 listed for maybe few hours, then they deleted it. They still list other out of stock products there.<p>To this day Pee foundation acts shocked, SHOCKED I TELL YOU every time someone complaints about official distributors being scammy. Whole thing would go a lot smoother (from the client perspective) if they didnt shield predatory marketing tactics of those resellers. Today I understand it wasnt rPi fault, but Im sure other people dont, and acting as a PR for element14 will never work if you promise X and element14 silently delivers X+super cheap piece of crap at 4x the price (before taxes) behind your back.
This is a crappy article about realizing the need of cache in front of dynamic websites.<p>Wow.<p>PHP haters: yes, PHP is crap, and we should all code in C, because nothing beats C in speed. ( Except for Perl in regex land. )<p>WordPress hater: the WP core itself is not that bad. The themes and the plugins, those are the real monsters.<p>Article owner & WordPress users: there are pretty good cache plugins already for WP, you needn't have to write another.
Er, so they rolled their own custom caching system?<p>Isn't caching one of the first recommended ways to improve the performance of, well, any mostly-static content site?
There are caching plugins for Wordpress, and you can configure Nginx to serve pages from the cache if no relevant cookies are set. So this feels a little like it's showing lack of knowledge about what's been done before.
You can run Php 7 and Nginx, that would be faster and stable.
When running nginx should use the nginx proxy caching features together with Wordpress that is very very fast!<p>Why not benchmark a raspberry pi cluster ?
Wouldn't it be better to setup a caching reverse proxy like Varnish? I bet there are configuration examples out there to help you run it with Wordpress.