Forgot your password?
typodupeerror
Earth Facebook PHP

The Environmental Impact of PHP Compared To C++ On Facebook 752

Posted by Soulskill
from the efficiency-is-overrated dept.
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."
This discussion has been archived. No new comments can be posted.

The Environmental Impact of PHP Compared To C++ On Facebook

Comments Filter:
  • people use PHP? (Score:1, Insightful)

    by Anonymous Coward on Sunday December 20, 2009 @11:54AM (#30504224)

    I remember when it was the script kiddie's substitute for cgi-perl. What does it offer from a theoretical and engineering PoV, apart from a Visual Basic learning curve?

  • Ridiculous (Score:3, Insightful)

    by SashaM (520334) <msasha&gmail,com> on Sunday December 20, 2009 @11:57AM (#30504242) Homepage
    That's a ridiculous way to analyze it. What about the environmental impact of the extra time required to write the same functionality in C++? What about the impact of whole classes of C++ bugs that don't exist in C++ (and, perhaps, vice versa) with the downtime or security breaches resulting from them? Or a hundred other ways in which writing all that software in C++ would be different of which I can't think at the moment?
  • by Pieroxy (222434) on Sunday December 20, 2009 @11:59AM (#30504262) Homepage

    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?

  • by Darkness404 (1287218) on Sunday December 20, 2009 @11:59AM (#30504264)
    The thing that this article fails to see, is that some languages aren't for everyone. A PHP programmer who turns out good PHP code isn't going to magically make the same level of code for C++. It also doesn't see that Facebook can't be down for longer than an hour at most, otherwise risk user outrage. After all, they have many, many, many users and for it to go down for a day would be akin to Google going down for a day or so. The difference being that if Google is down for a day, most users can use Yahoo, Bing, Live, WolframAlpha, etc. to search. Not every Facebook user has a MySpace.
  • 10:1... Really? (Score:5, Insightful)

    by tixxit (1107127) on Sunday December 20, 2009 @12:01PM (#30504278)
    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.
  • by quickOnTheUptake (1450889) on Sunday December 20, 2009 @12:02PM (#30504296)
    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.
  • by LBt1st (709520) on Sunday December 20, 2009 @12:03PM (#30504304)

    I know your being funny but you've got a good point. Developing and maintaining C++ code is not like developing and maintaining PHP script. Which of course is why we have PHP to begin with. It's designed for the web and ease of implementation. Sure C++ would be faster running but not necessarily more efficient in terms of dollars.

  • No. (Score:5, Insightful)

    by A Friendly Troll (1017492) on Sunday December 20, 2009 @12:04PM (#30504308)

    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.

  • Why stop there? (Score:5, Insightful)

    by Freestonepilgrim (1397833) on Sunday December 20, 2009 @12:07PM (#30504330)
    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.
  • by zippthorne (748122) on Sunday December 20, 2009 @12:07PM (#30504336) Journal

    For something that is deployed to tens of thousands of machines..

    Is there some reason why these languages couldn't be compiled and optimized? Code is just the programmer's will expressed as text that the machine can somehow interpret, right? If there is so much PHP out there, why wouldn't/couldn't there be an efficient compiler (by which I mean something that produces executables and not just "executables that are really just an interpreter tacked onto a script")

    The dearth of such compilers on the market suggests to me that the gains wouldn't be as great as claimed for the majority of applications where interpreted languages are used.

  • Umm... no. (Score:4, Insightful)

    by NitroWolf (72977) on Sunday December 20, 2009 @12:07PM (#30504338) Homepage

    Does the author seriously believe that Facebook isn't running some sort of PHP compiling/caching service, like APC or something similar?

    It would be ridiculous for them NOT to be running something like that, which eliminates much of the advantage C++ would enjoy through being pre-compiled. While there still may be a reduction if Facebook were magically changed to precompiled C++ code, the reduction would be fairly minimal. In addition to that, you'd need to factor in the debugging and coding/compiling times, which would exceed the PHP times by an order of magnitude at least.

  • by Foredecker (161844) * on Sunday December 20, 2009 @12:10PM (#30504358) Homepage Journal

    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

  • by Anonymous Coward on Sunday December 20, 2009 @12:11PM (#30504378)

    Many many moons ago efficiency was everything. The CPU was expensive, the developer was (relatively speaking) cheap.

    Then Moore's law really started to kick in, and we needed a paradigm shift. Developers were more expensive, and CPU cycles could be had on the cheap. The mantra was "code it fast, and only worry about efficiency for the bottlenecks if at all".

    Fast forward to almost 2010, and we have web applications deployed on a massive scale. Guess efficiency matters again. Not only from a pure cost standpoint but also from a moral argument to cut back on greenhouse gases. Amazing that more people haven't seen this coming. Especially given that web services are normally free to the consumer, the cost side of the equation clearly matters.

  • Assuming... (Score:5, Insightful)

    by Xugumad (39311) on Sunday December 20, 2009 @12:13PM (#30504390)

    "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..."

  • Re:Ridiculous (Score:1, Insightful)

    by Taur0 (1634625) on Sunday December 20, 2009 @12:15PM (#30504420)
    That's not an environmental impact at all. Hardly. What you're asking is: "What's the environmental impact of employing more programmers?" Sure, let's say worst-case, facebook hires programmers that would have got another job elsewhere, that other company must now hire different programmers and it trickles down eventually until some people who were going to be unemployed get a job programming somewhere. Okay, so now those people have a job. Let's ignore the fact that you're essentially saying that we should cut down emissions by making people unemployed. It's true that having a job will probably cause them to contribute a bit carbon emissions than if they were unemployed, but studies have shown that the large amount of our personal environmental impact is non-reducable (around 50%), even if you were to go homeless and live on the streets, we might see maybe a 10-20% increase of their personal carbon emissions. For even a couple dozen programmers that's nothing compared to running 20,000 more servers per year and that's absolute worst case. What you're arguing is the economic cost for facebook, whether it's worth all the man-hours to make their severs more efficient. That's debatable, but if you want an example, you just have to look at Google where they have a team that is devoted to increasing efficiency, despite the fact that they are already running some of the most power-efficient servers in the country.
  • by Anonymous Coward on Sunday December 20, 2009 @12:30PM (#30504534)

    > 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.

  • Re:people use PHP? (Score:5, Insightful)

    by Lord Byron II (671689) on Sunday December 20, 2009 @12:31PM (#30504542)

    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?

  • by sqlrob (173498) on Sunday December 20, 2009 @12:35PM (#30504574)

    And everything exuding heat is perfectly natural, no problems there.

    The deaths and environmental changes from heat exchange in rivers near power plants don't happen, nope, uh uh.

    Water's perfectly natural you need it to live, no way to drown in it, nope, uh uh.

  • by peragrin (659227) on Sunday December 20, 2009 @12:38PM (#30504594)

    while true it ignores things like your comparing a simple search box, with millions of users who post multi megabyte files to their personal space for everyone to see. try it some day save a facebook user's page locally and see just how much data is coming down that pipe, on top of the scripts that are running.

    Your comparing googles front door with facebooks entire company. Google probably has that many servers running web crawlers, and twice over again to store that massive database they use.

  • by Znork (31774) on Sunday December 20, 2009 @12:43PM (#30504642)

    "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.

  • by jimicus (737525) on Sunday December 20, 2009 @12:47PM (#30504678)

    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?

  • This is stupid (Score:3, Insightful)

    by Fnkmaster (89084) on Sunday December 20, 2009 @12:58PM (#30504760)

    Companies use PHP to develop and run web app functionality because it saves them huge amounts of time and money over rolling out the same thing if you were to write it all in C++. Realize what the cost structure of a company like Facebook is - the amount they pay their engineers, marketing personnel, and so on is significantly more than their amortized server expenses and server operating expenses (including energy costs, etc.).

    Furthermore, the 10x speedup assumption seems ridiculous - how much time is spent on their server in compute-intensive PHP loops where huge gains would be made from switching to C++? And how much of the "code" is really database queries of various sorts? Furthermore, you can generally isolate small areas like that in your codebase and rewrite them as modules in C or C++ to be invoked from PHP land - and if they could easily cut their server expenses even in half (let alone by 90%) by having a few engineers spend a few weeks rewriting some components, don't you imagine they've probably set about doing that already?

    Re-casting a discussion in terms of greenhouse gas emissions or energy use doesn't change any of this - saving energy generally means saving money, unless it takes more expensive resources (such as 100s of humans, who have to spend hundreds of months re-writing code in C++, while they, their families, and dependents emit tons upon tons of greenhouse gases, use electricity, buy groceries, and so-on and so-forth). The cheapest solution certainly isn't always the most environmentally friendly solution (such as when negative externalities are involved - lower labor and pollution standards in China, for example, that make a less "green" product manufactured there less costly in the US), but a vastly more expensive solution that no company in its right mind would implement isn't necessarily greener just because it might save some electricity and a few servers once it was implemented.

  • by Anonymous Coward on Sunday December 20, 2009 @01:00PM (#30504776)

    Obviously lesser number of servers for a lesser CO2 footprint also means cheaper server infrastructure. If that was the case, don't you think FB would have done it long ago? Economic forces are the main drivers of technology innovation in social networking!

  • Re:people use PHP? (Score:5, Insightful)

    by Pteraspidomorphi (1651293) on Sunday December 20, 2009 @01:02PM (#30504810)
    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.
  • Re:people use PHP? (Score:1, Insightful)

    by nxtw (866177) on Sunday December 20, 2009 @01:12PM (#30504872)

    It's got a very rich set of features that are aimed straight at making web development dead simple.

    No, features that make web development "dead simple" are those that actually do something to make web development simpler - such as built-in form input validation based on a set of easy to define rules, or generating a set of pages to create/read/update/delete data based on a database schema.

    The syntax is fairly straightforward and familiar, being a typical mishmash of shell scripting, C and perlisms.

    You contradict yourself.

    It was built from day one to integrate with Apache, it's not a nasty bolt-on hack like mod_perl.

    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.

    It's in-process so there's no startup overhead like with CGI

    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.

  • Re:Why stop there? (Score:3, Insightful)

    by dkf (304284) <donal.k.fellows@manchester.ac.uk> on Sunday December 20, 2009 @01:12PM (#30504890) Homepage

    Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.

    You might think so, but it's not as simple as all that. You also have to take into account the CPU's caching behavior; large numbers of inlines can (i.e., I've seen it happen) make the size of the working set too large to fit in L1 (or even L2) cache. That in turn means that you're taking a substantial performance hit. What's better, the size of those caches is dependent on exactly what sort of processor you're working with, so compilers don't take them into account.

    Inlining is a trade-off, as it increases the size of the object code in return for removing the cost of a function call. (It's also total poison for any ABI which needs long-term version management, since it effectively bakes internal details of the called objects into the callers' code, even if not at the source level. But I'm digressing) And yet modern CPUs have pretty decent branch predictors, and so the costs of a function call are often very low to almost non-existent...

  • by shogun (657) on Sunday December 20, 2009 @01:15PM (#30504908)

    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.

  • by Tony (765) on Sunday December 20, 2009 @01:16PM (#30504914) Journal

    Yes. I know the difference. C is an elegant if simple language, which is hard to program properly. C++ is an abomination that attempted to take the elegant, simple nature of C by bolting on spare body parts from dead object-oriented corpses, resulting in a language that is neither simple nor elegant, which is even harder to program properly.

    See, I know the difference.

    But if the point is to gain efficiency, why would you stop at C++? It's not a magical perfect balance of performance with elegance. C would give better performance than C++.

    Sure, there's the non-OO tradeoff (though you could quite easily gain the benefits of OO, though not as elegantly as C++), and then you don't have to deal with fucking templates (which are really nice to program, but a bitch to clean up when someone else has fucked them up for you).

    The premise of the article is stupid, and shows a pure lack of understanding of PHP, web service architecture and implementation, and a not-inconsiderable dose of C++ fanboi-ism.

  • Re:people use PHP? (Score:3, Insightful)

    by harlows_monkeys (106428) on Sunday December 20, 2009 @01:18PM (#30504928) Homepage

    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

    So mod_php is not a nasty bolt-on hack?

  • by betterunixthanunix (980855) on Sunday December 20, 2009 @01:21PM (#30504942)
    "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.
  • by Stele (9443) on Sunday December 20, 2009 @01:23PM (#30504972) Homepage

    Maybe you should learn the language first. It seems there are an awful lot of people who love to comment on the complexity and performance of C++, who never bothered to really learn the language. Yet this doesn't stop them from pretending the be experts on it.

  • Re:people use PHP? (Score:5, Insightful)

    by hardburn (141468) <hardburn&wumpus-cave,net> on Sunday December 20, 2009 @01:34PM (#30505026)

    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.

  • by betterunixthanunix (980855) on Sunday December 20, 2009 @01:37PM (#30505060)
    Part of the issue is the culture surrounding C and C++ code: there is a demand for backward compatibility. The C++ standards committee is very wary of breaking compatibility with previous editions of the standard, notwithstanding the breakage that compiler writers introduce. Thus, we are left with antiquated and frankly dangerous features that should not be used, but which novices wind up using anyway.

    Strings are a perfect example. The C++ standard defines a string type that is decent enough and fixes a lot of problems associated with C-style strings. However, because of the demand for backward compatibility, C-style strings remain in the language, remain in use in parts of the library, and continue to wreak havoc on C++ programs.

    I am not saying that the backward compatibility is a back thing -- in fact, I appreciate it very much, given the large body of old but useful code out there -- but I cannot deny that it creates problems. What I am saying is that I can see why someone would develop a new language to replace C++ instead of just writing a C++ library, given that there are a lot of people who write new code using these out of date features, thus creating a stream of horror stories about C++.
  • by I cant believe its n (1103137) on Sunday December 20, 2009 @01:44PM (#30505124) Journal
    IBM is working on [infoq.com] a PHP compiler to create bytecode for the JVM. Using P8 as it is called, you can run your compiled PHP programs on a java application server such as Tomcat or JBoss.
  • by Firehed (942385) on Sunday December 20, 2009 @01:46PM (#30505142) Homepage

    Which would be very relevant if Facebook was doing heavy number-crunching. The only numbers on the site are comment and friend counts, which isn't especially taxing work (especially since it's all de-normalized). The majority of FB is database activity and transforming that into HTML and JSON. If you want to place blame for inefficiency, MySQL would probably be your best bet.

  • by g0at (135364) <ben@@@zygoat...ca> on Sunday December 20, 2009 @01:51PM (#30505188) Homepage Journal

    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.

    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?

    What? Your logic is circular. PHP did not have standard libraries for XML (etc.) until after it existed, obviously.

    PHP was invented as a lightweight server-side preprocessor as an alternative to CGI, not as a general-purpose systems-engineering low-level compiled language.

    (I don't disagree with your gist that PHP is not well suited to many of the jobs it's used for today, but I wanted to clarify the history.)

    -b

  • Wasted Energy (Score:3, Insightful)

    by ChaoticCoyote (195677) on Sunday December 20, 2009 @01:53PM (#30505196) Homepage

    Isn't this "study" a waste of energy?

    I am a C/C++ programmer by trade; I'm not fond of PHP. Yet this "C++ saves energy over PHP" argument smells like more selfish politics to me. And selfish politics is what is bringing doom down on humanity's head -- the use of PHP vs. C++ is a sideline, a distraction, and only truly valuable for people who have a philosophical axe to grind.

    You want to save a lot of energy? Shut down all the computers running MMOs. And stop wasting cycles looking for alien signals in cosmic radio waves. And get rid of banal YouTube videos... and... the list is endless. The science behind Global Warming is being used to further political and social agendas that have little or nothing to do with adapting our species from a potential environment change.

    In the end, selfish politics will kill us all. We will become a footnote in history is we do not discover enlightened self-interest.

  • Green Languages?? (Score:3, Insightful)

    by nurb432 (527695) on Sunday December 20, 2009 @01:54PM (#30505204) Homepage Journal

    Ok, this has gone WAY too far .. we all need to just take a step back..

  • by sam_handelman (519767) <.skh2003. .at. .columbia.edu.> on Sunday December 20, 2009 @02:11PM (#30505338) Homepage Journal

    Computer programmers are people with their own carbon footprints, $FLATULENCE_JOKE. So, people have raised objections to the underlying efficiency argument, I tend to agree with the people who estimate that the energy savings would be less than 10-fold, but it's not like I've looked at the diagnostic output of their servers.

      Labor costs money, right? So if you assume that $X million worth of servers and electricity are cheaper than $X million worth of programmer time to reimplement the whole mess in C, then it's probably minimizing the carbon footprint to leave it alone. This ought to be a very simple business decision.

      There are certainly cases where this is not true, but for most purposes, dollars spent on computer programming go directly to carbon footprint. I'm a Socialist, certainly not a free market fanatic by any stretch, but when it comes to spending millions on highly specialized, skilled labor to reduce carbon footprint, I doubt that it's worth it unless the electricity you save costs more than the specialized labor.

  • by quickOnTheUptake (1450889) on Sunday December 20, 2009 @02:38PM (#30505498)
    Honestly WTF are you talking about? AJAX moves rendering/layout of dynamic content to the client. Ergo, it is going to reduce the processing necessary on the server to do any given job.
    I could copy and paste each paragraph of your post followed by some comment to the effect I have no idea how the paragraph is relevant, but I will spare the readers and just pick a couple general points of confusion.
    You seem to confuse static (plain html, something that does not enter into the conversation _at_ _all_) with server generated (precisely the sort of thing PHP is used for). E.g.,

    in fact, for static content, it can be highly efficient. . . . the majority were serving static content that was pregenerated and refreshed every so often

    Again, no one is talking about static content, including GP who was talking about forms, and server generated pages.
    You also seem to be confused about the general load on the server (factoring in thing like total MB served or something) as opposed to precisely the CPU load (again this is what we are talking about: no one cares about the fact that more complex web sites need CSS and JS files served up). E.g.,

    The AJAX code itself must be sent, at the very least, as well as the various UI elements and CSS that are necessary with AJAX -- all of which is still being served like a static page.

  • by calzones (890942) on Sunday December 20, 2009 @03:07PM (#30505712)

    You cache pages on your server so that instead of going to the database to fetch info, the info is already there.

    Until you have a good reason to believe the info has changed. Say, the user updated something or someone posted a message. Then you go back and get new data and cache it again.

    You also cache page components. Parts of the page that are on a different update schedule than other parts of the page may be cached separately or not at all (like ads).

  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Sunday December 20, 2009 @03:10PM (#30505732) Journal

    Why is it that a decent PHP (or Python, or Ruby) MySQL binding couldn't do the exact same thing?

  • by porneL (674499) on Sunday December 20, 2009 @03:41PM (#30505998) Homepage

    Developers that are diligent enough to make only 1 memory-related bug/year can certainly spell variable names correctly.

    If you have statically typed language, you rely on types. If you have dynamic, you rely on unit tests. Both are probably equally slow :)

  • by mysidia (191772) on Sunday December 20, 2009 @03:44PM (#30506026)

    I think it's fair to say that FB servers generate a large amount of database I/O.

    And their PHP code is likely running a lot of graph flow, pattern matching, and other data mining algorithms.

    Including plaintext indexing and search algorithms

    Remember, the whole point of the social network from an advertiser perspective is to select people on the network who are most likely to be interested in certain ads.

    This suggests a lot of elaborate DM on FB's part.

    Just because the intensive computations aren't obvious to the end-user, doesn't necessarily mean there is no heavy numerical computation being done behind the scenes.

  • by Bodrius (191265) on Sunday December 20, 2009 @03:47PM (#30506038) Homepage

    What kind of work were those 10K req/sec on your own custom server doing? Was it a standard db-backed web app, or something more specialized and computationally intensive?

    Not that I doubt the difference you saw - but I'm still skeptical of the 10:1 factor as applied to Facebook servers, which seem relatively standard webapp cycle (request -> datastore lookup -> html), *just from the programming language*.

    Admittedly, I don't do PHP, so the language could be as bad and impossible to scale as you claim. But from their architecture description, I really doubt the request spends enough time (>= 90%?) in PHP computation to make *any* change there translate into a 10X improvement.

    At least on my own experience, once you get into the '~1K req/sec' scenario on that type of webapp, the middle-tier code is rarely your main perf headache. You spend more of your time ensuring your data sources (sql+cache + any other services) keep up, and your middle-tier code spends much of its time waiting for whatever went out the socket to come back. There is always some perf improvement to make on the middle-tier, but if the request spends 90% of its time on the presentation layer... well, that's usually a perf bug, not by design.

    There are good reasons to justify the cost of switching away from PHP - and they seem to be aware of them. But order-of-magnitude perf improvements would more likely result from architectural and datastore improvements - and sensibly enough, that seems where their efforts have focused.

  • PHP vs. C++ (Score:4, Insightful)

    by Brian Knotts (855) <bknotts@cascadeacc e s s .com> on Sunday December 20, 2009 @04:05PM (#30506170)

    This is idiotic, and is typical of the kind of pseudo-science underlying much of the climate alarmism currently en vogue. Like a lot of things, it is pretty much impossible to quantify which language ultimately uses more power, because of all the variables. As others have pointed out, you might save some power in the deployment of the code, but you would surely use more power in the development of that code. Then, you have to figure out what the total impact of that is, since you'd have more man-hours of coding, using human coders, who sit at desks, in offices, which must be heated and cooled, etc., etc.

  • by GreatBunzinni (642500) on Sunday December 20, 2009 @04:21PM (#30506294)

    I once rewrote a bit of software that some MIT grads did. Theirs was 20K lines of C++, used 110 MB ram (constantly newing and deleting), used dozens of threads (constantly spawning and harvesting), and drove the system to its knees (90% system, 10% user load). My 2K (yes, one-tenth) lines of straight C used 5 threads (preallocated), a configurably preallocated ring buffer (about 100K in practice), and used less than 5% of user time with no measurable system load. And I was able to do this adding functionality and improving the reliability. Very few defects in 2000 lines of C.

    That's nice and all. I'm currently finishing my master's and for my thesis I'm writing an application in C++ and therefore I believe I'm in a similar situation as your MIT grads were. The thing is, in paper I have 1 year to finish my project, which could only start 2 months into the school year. Then it isn't very possible to properly design the application because, as the software is part of a research project, you are by definition learning the stuff as you go along. On top of that you have the ever common screw ups -- bugs, redesigns, rewrites... you name it. And if that wasn't enough, you have to do that part time, while juggling classes, meetings and presentations.

    That is a recipe for disaster. It isn't at all possible to spit out a perfectly oiled, academically immaculate application under those circumstances. Heck, I'm just a couple of months into my project and I already compiled a small list of features I should rewrite but that I can't as I can't afford the time. So it's perfectly natural that when someone looks into my code they say "hey, I can write this a whole lot better than him". Yes, you can. So can I, actually. Yet, I had to write that under circumstances that made it a whole lot harder to do a better job at it.

    Nonetheless, as you can attest to it, your MIT grads' application, although with it's flaws, does run just fine. Not perfectly but fine nonetheless. And if it's possible for some third party to pick up their work and reproduce the exact same functionality under less time and with such an ease that the people rewriting it can have the luxury of looking into details such as preallocating threads and ring buffers then that's a good sign they successfully accomplish what they aimed to do. And that's what really count.

  • by D4C5CE (578304) on Sunday December 20, 2009 @05:50PM (#30506856)
    Their decision for using PHP might have to do with being able to get their business up and running now using PHP rather than envisaging go-live a few years down the road with their developer resources and learning curve adjusted to C++ (which in all its well-deserved glory does take its time to master). Probably C's savings in power don't outweigh PHP's savings in manpower.
  • Re:people use PHP? (Score:5, Insightful)

    by shovas (1605685) on Sunday December 20, 2009 @06:09PM (#30507028) Homepage

    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...

  • by Colin Smith (2679) on Sunday December 20, 2009 @06:56PM (#30507374)

    Running a server is cheap.
    Paying a developer is not.

    Civilisation is largely about the multiplication of human effort through the consumption of energy and automation. So, we multiply this developer's effort by a couple of thousand when running one machine and then do the same on another several hundred machines beyond. Each costs several thousand dollars to purchase and several thousand more every year in electricity, in cooling, networking, management and maintenance.

    So, the effects of developer incompetence are also multiplied several thousand times often across hundreds or thousands of systems. Millions if we're really lucky.

    So it isn't just one server, it's just one extra datacenter. It often pays to hire better people.

    running a server for a day - $1

    You think you get a real server for that? You get a tiny division of a server for that kind of money.

    2) why doesn't these big server farms start looking at migrating code from PHP to C or C++ when the PHP+web design is solid?

    The network effect. They migrate to Java instead.

    Speed to delivery is nearly always primary importance.

    Indicating speculative projects and disposable code.
     

  • Facebook. (Score:1, Insightful)

    by Anonymous Coward on Sunday December 20, 2009 @08:27PM (#30507820)

    What about just turning off facebook, the entire thing is a collosal waste of time. And while your at shoot all the users as most of them are idiots who are a waste of space.

  • by tomhudson (43916) <`moc.nosduh-arab ... `nosduh.arabrab'> on Sunday December 20, 2009 @11:33PM (#30508716) Journal

    Yes, it is harsh, but anyone who has not programmed in c and assembler, and then spouts off nonsense about how php can't possibly be 10x slower, doesn't have the programmer mind-set.

    That mindset includes understanding the runtime environment - which means knowing the limitations of your tool - in this case php. That means you'll not "have" to do something in php because "when all you know is php, everything looks like it needs a script" rather than a different tool.

    Case in point - generating test data. Say you want half a billion examples stuffed into a db. You can run a script, which will take forever, or you can write it in c. Real-life example - a "world" measuring 8k x 8k cells, with each cell also measuring something like (iirc) 100 x 80. You can write a script to generate all that, and it will take a week to run (actually, it would have taken 220 hours). Or you can take an hour to write a similar program in c, let it run during lunch (a longish lunch - an hour and a half), and get back to work in the afternoon.

    That's why I'm a bit harsh on the "script it!" crowd. They're not very imaginative or curious, or they would learn c - it's not THAT hard.

  • by Waccoon (1186667) on Monday December 21, 2009 @02:07AM (#30509472)

    Ever read bad PHP code?

    My hobby is refactoring PHP code. Note I say hobby, and not job.

    After cutting my teeth with C, I moved on to web development with Perl. I was really annoyed at all the quirks in that language, namely, bizarre subroutines instead of functions, and clever regular expressions everywhere. Perl was just a pain, and I still don't like it! So, I decided to give PHP a spin, and I liked it because it was closer to the C code I used to write.

    It didn't take long for me to realize there was something seriously wrong with the language. After reading up on its history, I realized the problem: PHP is a crappy template engine that has been "upgraded" into a language over the course of many painful years. Horrible inconsistencies and limitations abound, names of functions make little sense, and it's taken years for even the most basic facilities to be kludged in. References work in reverse? I have to test for automatic quotes at runtime to make sure I don't double-encode input? Some text functions are binary safe and others aren't? Completely different APIs for MySQL 4 and MySQL 5? Yeah, okay... thanks.

    I went out of my way to study the language and write code correctly, but I can't blame people for writing bad PHP code. PHP is the Windows of the web development world. Nobody really designed it, it just kind of "grew" out of some little hack project and caught on among the rookies.

    The only reason I work with PHP is because I want to make redistributable code that will work on shared servers, where people cannot install a new language on the server. Perl and PHP are your only options for that, and Perl can be a bitch to get running correctly, depending on the server's security policy. I don't care if Python makes a comeback or Ruby catches on, or whatever. I just want... something else to work with.

  • by butlerm (3112) on Monday December 21, 2009 @03:11AM (#30509694)

    Ergo, it is going to reduce the processing necessary on the server to do any given job

    Any given job, yes. But if there are a lot more "jobs" (i.e. more requests that require server side processing), the efficiency of the language used on the server side tends to become more critical, not less, especially if the per request overhead is significant, something that happens to be one of Facebook's primary complaints about PHP.

  • by adamchou (993073) on Monday December 21, 2009 @03:59AM (#30509854)

    While you're churning away your super optimized C code which runs faster than god knows what and finally debugging the library to handle your super cusotmized tcp/ip replacement, I'll have already rolled out the application you wanted to do, but in some "non-programming/scripting" language like PHP, Ruby, Python, or hell... even Java.

    There's a purpose for every language out there and frankly, writing some form of code to have a computer perform specific tasks is called programming. So please contain your ego instead of going off and spouting things like...

    scripting (which isn't "real programming"

  • by vegiVamp (518171) on Monday December 21, 2009 @07:19AM (#30510656) Homepage
    > Sure C++ would be faster running

    If you take APC or similar compile caches into account, I think you'll find that the gap is remarkedly smaller than you'd expect. It'll never close entirely, but given that I've seen 20x speedups on some pages, the benefit is huge.

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]

Working...