Slashdot Mirror
The Environmental Impact of PHP Compared To C++ On Facebook
Kensai7 writes "Recently, Facebook provided us with some information on their server park. They use about 30,000 servers, and not surprisingly, most of them are running PHP code to generate pages full of social info for their users. As they only say that 'the bulk' is running PHP, let's assume this to be 25,000 of the 30,000. If C++ would have been used instead of PHP, then 22,500 servers could be powered down (assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code), or a reduction of 49,000 tons of CO2 per year. Of course, it is a bit unfair to isolate Facebook here. Their servers are only a tiny fraction of computers deployed world-wide that are interpreting PHP code."
What about all the cycles compiling and debugging C++ code? Or all the trees torn down for C++ books? Or the environmental impact of C++ developers? I mean, have you ever had to share a cube with one of them? Pheewww.
Run and catch, run and catch, the lamb is caught in the blackberry patch.
Seriously, is somebody taking seriously the 1 to 10 ratio of the story?
I mean, maybe raw execution of pure code is going 10 times slower in PHP than C++ (ouch, I didn't know that) but even then, it's far from representing the same ratio when talking about a number of servers. You have to take into account all other parameters (disk access, network, IO, etc... Those aren't 10 times as slow in PHP one would guess).
I would be astonished if this ratio is close to be the truth. Does anyone have any insight/information on this?
Write boring code, not shiny code!
What about the impact of whole classes of C++ bugs that don't exist in C++
I've spent many a sleepless night worrying about C++ bugs that don't exist in C++. I'm glad I'm not alone.
First posting isn't trolling. It's...first posting.
That's crazy. 10:1 is incredibly unfair. Especially when you consider that a cached C++ page takes just as much time to return as a cached PHP page. On top of that, majority of the work done is just searching a database. If would imagine a large part of processing a page is in getting and returning data, which is then up-to-the database. He is using stats that say PHP is 10 slower for running through loops, math that type of crap. Says nothing about querying a database then doing some minor presentation related logic. If I had to guess, for a web page the average "efficiency gain" of using C++ would be under 2x.
Just serve up plain text files. Anything else is pure decadence!
I'm thinking that these scripts are just thin front ends to a massive db. Thus, a lot of the computer's time is going to be spent on I/O, and a lot of the processing is going to be taking place in the db itself, which is probably written in C.
Mod points: Guaranteed to remove your sense of humor.
Side effects may include gullibility and temporary retardation
Simply put: no.
The reason why they have so many servers is because Facebook contains so much data. The servers are there for a reason, and the reason is CACHING.
The overhead of PHP is very small for a platform that is all about sharing data and the bulk of processor time surely goes towards fetching that data in the first place. What, do you seriously think that when you hit your home page on Facebook, there are database queries issued for that? Lulz.
Besides, I'm almost sure that FB uses something like Zend Accelerator, which increases code execution speed a lot.
Anyway, just no.
A PHP programmer who turns out good PHP code
The Easter Bunny, Santa Claus, a PHP programmer who turns out good PHP code, and Steve Balmer are in the four corners of a room. In the center of the room is a chair. Who throws the chair first?
Steve Balmer, because the other three don't fucking exist!
Exactly. He using stats from benchmark results from pure number-crunching tests. Seriously, here are the tests: pidigits, reverse-complement, regex-dna, k-nucleotide, n-body, fasta, binary-trees, fannkuch, spectral-norm, mandelbrot. Yep. Looks like stuff a web page would do... The biggest bottle neck is probably data access, in which case the language really doesn't make much, if any difference.
Why not rewrite everything in assembly? This comparison comes to a conclusion without any facts to back it up. As others have pointed out there is development time and compile time associated with C++... and what about ongoing development? Where does 10-1 come from? Are you assuming they aren't doing any optimization or using any sort of accelerator? I've personally re-written code in C++ from php, and then done the comparison. In our case, we decided the extra maintainability was worth the approx 10-20% increase in speed we saw.
What a troll. Any point or argument based on assumptions is very weak. Here there are two: "..Let's assume this to be ..." and "...assuming a conservative ratio of 10...".
Don't make stuff up.
-Foredecker
Jibe!
"assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code"
ARRRRRGGGGHHHHHHHHHHHHH
Why? On what evidence? I mean, I hate PHP as much as the next guy, but last time I wrote a web application platform in C++, I got to the end, analysed the result and went "Great, I've made the fast bit even faster. Now, about that database engine..."
It's got a very rich set of features that are aimed straight at making web development dead simple. The syntax is fairly straightforward and familiar, being a typical mishmash of shell scripting, C and perlisms. It was built from day one to integrate with Apache, it's not a nasty bolt-on hack like mod_perl. It's in-process so there's no startup overhead like with CGI. I've been using it on some pretty large web sites for years and it's never let me down.
no longer working for cnet
.. because I didn't ever think I'd be defending PHP.
However, it is a much better choice for a web application than C or C++ - and I say that as someone who codes C, C++ and Java for a living. There are no decent web frameworks for C++, memory management is still an issue despite the STL, and the complexity of the language means both staff costs and development time are inflated. Peer review is harder, as the language is fundamentally more difficult to master than PHP. Compared to Java, the development tools are poorer, and things like unit testing a more complicated despite the availability of things like Cppunit. There's no "standard" libraries for things like database access, and no literature that I am aware of that describes how you would go about designing a framework for C++. You'd most likely end up porting something like Spring to C++, and the even if you published your code on the web, I doubt much of a community would build up around it.
If you want a less contentious argument, and one which can be backed up with hard evidence, then argue PHP that should be replaced with Java. A well written Java web application, using a lightweight framework such as Spring or PicoContainer, should outperform ad-hoc C++ code.
> a PHP programmer who turns out good PHP code
Yeah, that'd be me. Hi! We do exist, and there are plenty of us.
Granted, we tend to be outnumbered 100:1 by the PHP programmers who produce complete crap. The same is probably true of nearly any language.
I use it because I can code up relatively fast, relatively secure dynamic websites in a very short amount of time. I can install it on a webserver in seconds and it integrates beautifully with Apache and MySQL. Maybe there is a better solution out there, but PHP has always done what I need it to and I've never had a problem with it. It's never given me a reason to look elsewhere.
What I don't understand is all of the PHP-haters out there. Really, who cares if it is "the script kiddie's substitute for cgi-perl"? Isn't the proper measure of a tool if it does what you need it to and not who else uses it?
Even better, TFA is a page for a C++ web toolkit. It's just spam.
Yes, PHP is a heck of a lot slower on proccessor-bound tasks than C++. In a pure benchmarking contest, no doubt C++ will win.
But what about when both languages have to query a database (be it mysql/postgress/oracle, etc)? In this case, both are blocked on the speed of the database. a 15 ms query takes 15 ms no matter what language is asking. Facebook is not calculating pi to 10 gazillion digits, and it is not checking factors for the Great Internet Mersenne Prime Search. It is serving up pages containing tons of customized data. This is not proessor-bound... it is I/O bound both on the ins and outs of the database and the ins and outs of the http request. It is also processor bound on the page render, but the goal of this many machines is to cache to the point where page renders are eliminated.
Once a page is rendered, it can be cached until the data inside of it changes. For something like facebook, I bet a page is rendered once for every ~10 times it is viewed by someone. Caching is done in ram, and large ram caches take a lot of machines.
So lets look at those 30,000 machines not by their language, but by their role. We can argue the percentages to death, but lets assume 1/3rd are database, 1/3rd are cache, and 1/3rd are actually running a web server, assembling pages, or otherwise dealing with the end users directly (BTW, I think 1/3rd is way high for that.)
So 1/3rd of the machines are dealing with page composition and serving pages. If they serve a page ~10 times for every render request, then abtou 1/10th of the page requests actually cause a render... the rest are being served from cache. Those page renders are I/O bound, as in the example above - waiting on the database (and other caches, like memcached), so even if they are taking a lot of wait cycles, they are not using processor power on the box. The actual page composition (which might be 20% of the processing that box is doing), would be a lot faster in C++... So 10,000 servers, the virtual equivalent of 2000 are generating pages using php, and could be replaced by 200 boxes using stuff generated in C++.
So the choice of using php is adding ~1800 machines to the architecture. or ~6% of the total 30,000. Given that a php developer is probably 10x more productive than a developer in C++, is the time to market with new features worth that to them? I bet it is.
"development" also has one.
Not to mention clients. 20K servers is nothing compared to the millions of clients drawing higher power due to running looping flash commercials.
You can go to work in a F1 car, or your normal car.
I wish. My F1 always gets stuck in the gutter at the end of the driveway.
What C++ has always lacked, and PHP, Java and others do not, is a bundle of standard libraries that let you do things like process XML, talk to databases, and make templating EASY.
That's it. php does the same things C++ does, but go one beyond and add a rich library and of course, the ability to skip the "compile" step in the write -> compile -> test
I agree with you, but there's one small thing I don't get.
Faced with this piece of information, someone thought the logical thing to do was to, er, write an entirely new language?
"even arp drags a server down when you have 20K+ connects"
Are you perhaps a server admin in my company? I swear this is the best excuse for poor performance I've ever heard.
The author is pulling numbers out of his ass and has no clue about what uses most time (waiting for database results mostly), about PHP accelerators and about caching systems like memcached.
He's comparing performance of php script running on a raw PHP installation versus running a C++ version of the same script, doing calculations that almost never apply to real world scenarios.
I don't see how any company would use C++ to develop their whole systems except maybe for some CGI scripts. Not even Google does it, afaik they use Perl and Python a lot.
Anyway, the number of servers has no direct correlation to the programming language. Out of those thousands of systems, lots of them are read only database servers in a cluster, lots are only serving static files (thumbnails, images used in CSS files on people's pages and so on), some servers are used solely for memcached instances and content used very rarely, some are load balancers....
Basically, the author has no clue.
I always found Livejournal's presentation about scaling very insightful, especially as it's a pretty big site, just like Facebook and other big time sites. The second link gives a lot of details about how they fine tune mysql and other parts of the system, which just goes to show how the apparent speed improvement of C++ versus PHP can overall be actually insignificant.
http://video.google.com/videoplay?docid=-8953828243232338732&ei=3VUuS5-hLaKi2ALXqanJBQ&q=livejournal#
http://www.danga.com/words/2004_mysqlcon/mysql-slides.pdf
It wouldn't be so popular in first place if it was worthless. I wonder how much CO2 would be released into the atmosphere by the cars and computers of all the extra coders necessary to develop in C++ a website that could otherwise be developed in PHP, in the same period of time and with all other things equal. This is the same tired argument that can be used against *any* interpreted language. I love C++ - it's my favorite programming language - but I always use PHP for website development and I'll go on using it unless I'm forced not to.
A self proclaimed good PHP programmer... yeah there are about a 100 of those to every 1 that doesn't do that.
It probably is a valid excuse if you have 20,000 client machines connecting locally via ethernet from a B class subnet such that the arp tables on the server keep overflowing.
Of course if you, as a system administrator ever let such an environment be setup you probably are really good at excuses anyway.
Don't forget to take account of the energy required to heat the water for the extra coffee it would take to build it in c++. People always forget about the coffee:production ratio.
"ever read someone's c++ code? has it been a good experience?"
Sure, when the code is written by someone who really knows how to use C++. Ever read bad PHP code? Bad Java code? I have seen programmers do things like this:
int int1, int2, int3, int4, int6, int7;
No, that is neither a joke nor an exaggeration, and the missing number is deliberate. This is a declaration I saw on a recent project. This kind of poor coding is language agnostic, and it is entirely irrelevant whether someone is using C++, PHP, or even a language like Haskell (bad Haskell code is worse than that worst C++ code I have ever seen -- if you use a functional language, get it right!).
On the other hand, I have seen some maintainable C++ code, with appropriate and useful comments, well thought out classes and class relationships, and expert use of the STL. I once worked on a project with C++ code that dated back to the early 90s, and had been continuous updated to support new features and needs, to make use of the STL (yes, this can be written into old code without causing a disaster), and so support systems that did not even exist when the code was originally written.
Don't blame the language, blame programmers who never learned about good programming practices. Blame computer science programs that give people degrees they do not deserve. Blame an industry that will hire anyone who can write a hello world program and then assume that they are capable of writing a maintainable system with millions of lines of code. The best programming language in the world will not solve the problem of poor programmers and poor coding practices.
Palm trees and 8
Actually, Facebook uses APC to compile and optimize the code in the shared memory so it doesn't have to be compiled over and over again.
There are other libraries for caching PHP functions on many different levels as well, and they're open source, for the most part. Some real bright minds from Facebook and other large PHP applications have contributed to them.
Bottom line: PHP is quite powerful and efficient when built and extended properly.
mod_php has never integrated into Apache nearly as deep as mod_perl did. That is, lower level Apache APIs are not exposed to PHP. Using mod_php is an acceptable replacement for CGIs, but mod_perl does a lot more than that. That means taking over the entire server life cycle handlers to the point where, in Apache2, you can implement (say) a Gopher server if you want.
mod_perl is not a hack. PHP, as a language and an API, very much is.
Not a typewriter
It's more like you decide you want a whole new room dedicated to watching movies, but in order to add that to your current house you'd have to spend tens of thousands of dollars and get approval from city hall and your homeowner's association. Just for a fairly small addition.
So instead you decide to go build a new house the way you like it, from the ground up, and while you're at it you add ethernet outlets into the planning because you always wanted that in your old house but you would have had to take down the drywall in order to get them where you wanted.
Buckle your ROFL belt, we're in for some LOLs.
Your post is really annoying. Did you mean to be so obnoxious? And +5, Insightful. Come on, php isn't popular with slashdotters but whatever one calls reverse fanboyism it isn't cool either.
No, features that make web development "dead simple" are those that actually do something to make web development simpler...
Absolutely. And PHP does it. That's why it's so popular. There may be even more that can be done but if no popular language is doing it already that argument is kind of pointless.
You contradict yourself.
No he doesn't. You might not like scripting / dynamic languages but taking the best (or a good stab at taking the best) of scripting, C and perl can actually make some things more straight-forward. Need a regular expression? Used to function calls rather can syntactical regex? Need perl regex? preg_match.
Patently false. PHP has no dependency on Apache now, it originally used CGI, and continues to support CGI, FastCGI, and operation as a module in web servers other than Apache (such as IIS). The CGI startup overhead problem has many solutions, such as FastCGI, AJP, proxying, etc.
Patently missing the point. PHP and Apache go together so well it created the LAMP mindshare space.
But "not in-process" does not imply the use of CGI, and it does not imply the use of any system with long loading times. Furthermore, "in-process" is potentially insecure and can be less reliable - as all code runs in the same process.
Who cares? His point is startup cost which is generally higher for forks vs modules and you're just plain going to get more scalability compared to the traditional perl cgi forking method. Hence mod_perl.
Give me a break. You can dislike anything you want but why do you even bother when you don't have all the facts.
+5, Insightful. Dear me...
Selah.ca. Pause, and calmly think on that.