Handling server load for the Raspberry Pi Zero launch
blog.mythic-beasts.com
blog.mythic-beasts.com
1. Why PHP?
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.
2. Why WordPress?
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.
3. But why not build your own bespoke framework?
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.
4. WordPress caching plugins exist. Why don't you just use them?
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.
5. Why not use NGINX?
See a full article on this here: http://blog.mythic-beasts.com/2014/11/14/hiphop-and-wordpres...
6. What about hiphop vm?
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.
1. Concise code to express common constructs.
2. Easy for 3rd parties maintaining or extending software to understand what it does.
3. Easy for type system, tests, or static analysis to catch errors before they hit production.
4. CPU or memory efficient during runtime.
5. Higher uptime for interpreter and critical libraries.
6. Lower number of defects and vulnerabilities in both interpreter and common libraries.
7. Ease of writing portable code might matter to some in case they like shopping around for cheaper cloud vendors.
So, there's a start at a list with important metrics for missing-critical, long-term code in web apps. Got a link(s) showing PHP is equivalent to or better than competition in these?
If we're being honest every language has its weak points and things that are disliked even by its proponents. Efforts at improvement are more productively directed towards making things better on your own turf. Taking derivative and uninformed jabs at a language you already dislike and will never use is not a good way to spend your energy, nor is the energy of your opponents well spent in trying to overcome your biases.
I actually have this data for a number of systems languages from studies done in 90's and early 2000's. Despite much talk, I've yet to see a PHP proponent post such objective information in a discussion. So I asked again as I know somebody has to have done an objective analysis or comparison. Yet again, all we hear is (a) critiques are BS, (b) many people use it, and (c) therefore PHP is a good choice. Sounds solid to me! ;)
People may think they choose languages and runtimes for objective reasons, but objectivity is only a part of it. There are other factors like ecosystem support, public image, fads, suitability for a specific purpose, aesthetic aspects, and how well a certain language resonates with someone personally.
In this specific case, I believe there is zero value in convincing someone to use, say, PHP for something (in production or otherwise) if they already dislike the language for any reason. And it's not like you're missing out on anything either for not choosing PHP. There are plenty of options out there.
> I've yet to see a PHP proponent post such objective information in a discussion.
I'm probably not the best person to do this. While I use PHP and believe in certain contexts it's a good choice for me, I'm less sure about the benefits of evangelizing this in a greater context. There are lots of things in PHP that I actively dislike, as there are in any language I am proficient with.
> (a) critiques are BS, (b) many people use it, and (c) therefore PHP is a good choice
I think for several reasons PHP's advantages are minimized or even badly understood even by people who write big software packages in it. That's just my opinion, though. If you still want my atypical response to your points anyway, I'll give it.
Oh I agree. It's why I don't knock them for whatever they use for personal projects. Serious stuff I recommend we throw the objectively best we have at. Not PHP or many others for that matter.
"I think for several reasons PHP's advantages are minimized or even badly understood even by people who write big software packages in it. That's just my opinion, though. If you still want my atypical response to your points anyway, I'll give it."
The one advantage I see is a ton of existing code and programmers to draw on. One of same advantages for C. Also, a great pre-processor for HTML crowd stepping into programming. Original selling point unless I'm mistaken with ColdFusion doing same thing in business for data-driven apps.
Those are only two I know vs languages in same space. Certainly add anything that you think are advantages. I try to give everything a fair shake. ;)
I would not consider this an advantage per se, because exactly like C, it's difficult to find a certain type of programmer who cares about things like performance or has a real understanding of what is happening when their code executes. I see the same thing happening in the Node.js community. (PHP, C/C++, and Node are my primary languages right now, I'm certain the same thing happens everywhere else, too)
> Certainly add anything that you think are advantages. I try to give everything a fair shake. ;)
How gracious of you :P As I said, I feel I'm not really representing the PHP community or the direction it's heading right now, but here's my view:
As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby. My knowledge of PHP VM internals is limited, but as far as I saw last time, it's not fundamentally different from Lua's. There are some big WTFs in the syntax area, which I think is one of PHP's weakest points to begin with, but as far as expressivity and concision is concerned it's relatively powerful. Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard.
As for 2 and 3, well it's a dynamic language with an optional class system. As such it has the same weaknesses and strong points as other languages with those characteristics. Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns.
Which brings us to 5 and 6. PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right. Per-request execution sounds like a high-overhead situation, and in the past it was, but while there is undoubtedly some cost associated with it, the FPM engine is really quite efficient with it.
In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug. You can tailor your app's code paths with this execution model in mind, loading and initializing only what you need. Since the environment is torn down after a request finishes, there are no leaks or complex GC gotchas. Scaling up becomes easy, because state is not stored in your code. You can spin up as many servers as you like, distribute requests among them, and they don't have to be aware of each other. Retracing what happens per request becomes very easy, which is great for optimizations and debugging. And you get live code reloading for free. I love this, it's so simple and elegant.
Of course, there are lots of things this is unsuitable for, especially when you really do need a persistent app server. But even in these cases, it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API. I use this setup in some projects where Websockets or other persistent protocols need to run: the broker needs to be updated very infrequently, so it can have a gigantic uptime, and the backend PHP API gets updated all the time transparently with a git pull - nothing needs to be restarted, everything just works.
I strongly advocate this architectural style. Even for developers well-versed in Node, Go, etc, it's good defensive programming to split the application into two processes (broker and backend).
You might find the Pushpin project interesting. It's an attempt at generalizing the broker part, and it works great with a stateless PHP backend.
> You might find the Pushpin project interesting.
That is interesting, I didn't know such a project existed (kinda surprised actually). However, that's not a pain point for me at the moment. I maintain my own reusable broker module for Node/Websocket things, plug it into the NginX config and I'm ready to go. Plus it's not too hard to cook up one of these things if the need arises.
I agree. It's one of the few things about PHP that you see in both lists of advantages and drawbacks haha.
"As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby."
I believe it for 1, 4, and 7 but am skeptical on 6: internal quality and security. The few times I saw people dedicate time to PHP vulnerabilities were finding them 10+ at a time. Lua and Go should do better due to simplicity but I haven't verified that. Coverity reported Python having lowest defect rate of about anything at one point. Getting updates on scoring like that vs other dynamic and static languages might be a useful metric. Compared to most web stuff, I'll leave 6 at maybe.
"Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard."
They're foolish if so. Definitely a speed advantage for PHP given work (esp Facebook's) put into that.
"Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns."
I believe that. It was true for some other languages before. So, that solves 2 but 3 is still on table. Languages supporting strong static analysis, design-by-contract, advanced typing, and so on can do better than a PHP-like language. This includes dynamic ones extended with that stuff. So, 3 is a maybe leaning towards no if against application rather than scripting languages.
" PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right."
"In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug."
Definitely makes things easier to understand and reduces issues. Certainly an advantage against anything not supporting such a model where it's needed. Adds support on 5 given stateless reliability is easier to boost.
" there are lots of things this is unsuitable for, especially when you really do need a persistent app server. "
That's a lot of modern web apps, though, right? I can't guess at the percentage but "LAMP stack" implies databases and persistence are the norm.
" it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API."
Smart idea. I can see the potential gains. There's parallels in highly assured systems where we kernelize critical functionality, implement it robustly, and untrusted stuff just calls it often with interface checks. It's a proven method with lots of application. Do you have any resources on doing this right in web applications out of curiosity? Just in case I have to get back into that.
Conclusion
We started with 7 metrics. Your case showed it's roughly comparable to competition in 4/7, probably better on 1/7, a maybe on 1/7, and a stronger maybe (stateless) on 1/7. Rather than horrible, with these metrics it comes out as OK in most ways with advantages in some and potential disadvantages in just a few. So, baring new data or metrics, it's objectively Ok at this point compared to others with possible advantages in speed or error minimization at component level. I say possible because I've seen competitors do similar things. I'd do case by case comparisons there but PHP is overall OK based on your data.
It also gets hacked like there is no tomorrow, he he. What a joke! Seriously can you believe that that lolphp sub-reddit that I linked has been adding new entries steadily even after six years! Give me one language that can rival this feat!
Remember; Each one of those is a gotcha that can bite you when you least expect it. Forget everything. This alone should be enough to keep anyone miles away from this language.
Is that the official opinion of the Foundation?
Also Python isn't the only language we encourage. We ship Raspbian with Ruby, Java, Mathematica and more and have resources in many, including PHP.
Re 5: I found that nginx was way better at static resources, like images, CSS, and super-cached HTML. I imagine you use CDNs for the first two, but being able to selectively bypass Wordpress for the last is something nginx can do but I think Apache can't.
Edit: on re-reading, it's also a downloads server and apt mirror? I'd definitely use nginx, probably as a reverse proxy for Apache, because fewer configuration changes are needed that way.
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.
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.
Another form is "I saved the world from a trillion lines of PHP! And if we did this on AWS it would be many tens of thousands of dollars per month..."
Perhaps I should make sure I'm giving the author the benefit of the doubt:
"... you’d still need to make sure you can effortlessly scale to thousands of cores ..."
10k users peak. Thousands of cores? $30k+ a month? This is blatant misinformation.
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.
Or, if your needs are more complex, using an already established cache like the one in nginx or varnish, etc.
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.
# oversimplified, but...
$key=md5(http_build_query($_GET));
$content=apc_fetch($key,$success);
if ($success === TRUE) {
echo $content;
return ;# never invoke wordpress
}
# wordpress here
# some logic at the bottom to store what wordpress
# just rendered into the cacheSimilar 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. http://www.adafruit.com/pizero had $5 listed for maybe few hours, then they deleted it. They still list other out of stock products there.
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.
Wow.
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. )
WordPress hater: the WP core itself is not that bad. The themes and the plugins, those are the real monsters.
Article owner & WordPress users: there are pretty good cache plugins already for WP, you needn't have to write another.
Isn't caching one of the first recommended ways to improve the performance of, well, any mostly-static content site?
Why not benchmark a raspberry pi cluster ?
> During the day we improved and deployed this same code to the MagPi site including some horrid hackery to cache popular GET request combinations.
make me think they would have been much better served using a pre-existing solution (probably Varnish) that's built to do exactly this. This article reads like a major case of reinventing the wheel.
The funny thing for me is that they make it seem as if 10K concurrent users is a 'big deal' for a bunch of static pages. If you're not interacting in real time a little bit of caching or page generation will go a long way towards being able to serve up a huge number of viewers / participants.