

Facebook (PHP) is not very Copenhagen (Change to C++ to save planet) - waterlesscloud
http://www.webtoolkit.eu/wt#/blog/2009/12/17/facebook__php__is_not_very_kopenhagen

======
rbranson
What this article fails to note is that writing C++ code to serve up web pages
would be much less efficient from a human time perspective. You'd need many
more developers working, and the average American emits 20 tons of CO2 per
year. So if Facebook has 100 developers hacking PHP code, they'd probably need
at least 200, or possibly 300 developers hacking C++ code. 100 developers is
2,000 tons of CO2 per year (at average rates). From an economic standpoint, it
would make much more business sense to use carbon offsets. Not to mention that
a 10x end-to-end efficiency improvement is AWFULLY optimistic. I'd say 2x or
3x at best.

~~~
houseabsolute
There's a more glaring deficiency than that, which is that CPU is rarely the
bottleneck on a webserver.

~~~
rbranson
A "web server" in Facebook's cluster is just Apache+PHP. It doesn't do any
disk work. It's not reading anything from disk, as that gets forked over to
memcached or MySQL. If you've got thousands of boxes in this arrangement,
clearly reducing the CPU usage thru whatever means will get you more
efficiency.

~~~
leej
can you elaborate more on "no disk work" and forked over things? i didnt get.

~~~
anApple
The webserver will only do computations which data they get from other
services (memcache, etc...). They will never fetch the data locally, so there
is no local bottleneck except the local bandwith and the efficiency of the
code, thus the cpu.

~~~
leej
then only logical reasoning behind is cheap machines for webservers and very
powerful ones for "data" servers. otherwise network bandwith is only a
fraction cpu-storage one.

------
carbocation
Facebook makes heavy use of, and is one of the major contributors to, APC, the
opcode cache. Most of the time, Facebook is hitting this cache, so its
interpreted load is much, much less than this article estimates.

In other words, this article's author is railing against some imagined version
of Facbook running some imagined implementation of PHP, not the Facebook that
actually exists running PHP with opcode caching and memcached.

~~~
leej
facebook may be a contributor but apc has only a minor release for the last 8
months.

~~~
mechanical_fish
APC has lots of users. Judging the userbase of a piece of software by the rate
of major releases is like judging the speed of your car by the rate at which
it breaks down.

It's an opcode cache. It doesn't need to gain features until it can read
email.

------
jackfoxy
The reference used to justify the 10:1 superiority of C++
[http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php&lang2=gpp&box=1)
seems unlikely to have much bearing in this case. I doubt Facebook is
calculating the Mandelbrot set or traversing huge binary trees in PHP.And as
others have pointed out, CPU is hardly the only thing going on here.

Useful real-world benchmarks of even simple real-world systems are rare and
require a lot of resource (mostly human) to construct. Here's an example
benchmark I proposed once. [http://jackfoxy.blogspot.com/2009/10/time-for-
real-world-lin...](http://jackfoxy.blogspot.com/2009/10/time-for-real-world-
linuxapache-iis.html) At the time I couldn't find any bechmarks anything like
this. I haven't tried looking since, but I suspect no one has bothered. It's a
lot of work.

------
garyrichardson
Does that mean networks move bits faster and hard drives spin faster for C++
than they do for PHP?

~~~
prodigal_erik
It gets you closer to the theoretical maximum of your network and memory
busses. When a single machine can generate queries and lookups and log and
render results faster, you need fewer machines to handle a given load. I know
we increased our web front end capacity by 5x when we migrated from PHP to
Java that runs backend queries asynchronously, so we reallocated some boxes
and now we won't need to light up new hardware for a while. The inefficiency
of PHP really adds up when you reach hundreds of cores.

~~~
mechanical_fish
That sounds like an architectural change, not a problem with PHP's runtime.

It's quite possible that the solution to your particular problem can be better
expressed in another language than PHP, or will run faster under a different
language's runtime. This doesn't mean that PHP "is slow". It might mean that
your problem is an imperfect fit for a PHP-based architecture at your
particular scale.

~~~
prodigal_erik
We have made architectural changes, but not that day. We literally had a drop-
in replacement that did the same work but sustained 5x the request volume
before saturating on the same machines, with the rest of the datacenter
unchanged. (The async client was merely for latency, not throughput.)

I don't believe any PHP runtime can ever be the fastest solution for a
problem. The language requires runtime type checks and coercions inside the
operators and builtin functions, both keyed and ordered access to every
collection, ad hoc creation and destruction of variable bindings by name, and
dynamically switching to reference semantics for any existing value. Each of
these imposes a cost on passing arguments and evaluating expressions, and I
didn't find any of them paid off by making code much simpler.

------
rlm
It's Copenhagen, or København, not Kopenhagen :(

------
Asa-Nisse
It would be 1:20 if they wrote it in assembler. I write all my webpages in
Assembler and I eat bits for cereal.

------
DaniFong
Consider Cambridge physicist David MacKay's Without Hot Air, especially the
section "Every Big Helps."

[http://www.inference.phy.cam.ac.uk/withouthotair/c19/page_11...](http://www.inference.phy.cam.ac.uk/withouthotair/c19/page_114.shtml)

On a related note, I suggest the everyone run Wattzon.org to see where their
carbon footprint comes from. I found that while I was a much lower user on
everything else, heat accounted for 40% of my entire carbon footprint.
Immediately I ran around the house and fixed the duct vents that I could close
before, and now I'll have probably halved that, saving me $15 a month, $180 a
year, and 20% of my carbon footprint.

Seriously! Little fixes can make _huge_ changes.

------
henrikschroder
Why rag on Facebook? Smells like linkbait to me, why not argue the general
case? At least Facebook is _using_ their servers, what about all the unused
servers? Old servers that could be consolidated? Servers running even more
inefficient code than PHP?

------
jrockway
Good point. But I fail to see why C++ is the solution, when there are plenty
of other languages that execute just as efficiently but do not have C++'s
shortcomings. I would pick Haskell, but even good-old-Java will do just as
well as C++ for Facebook's workload.

------
PanMan
If facebook has 30K servers, I highly doubt they have 25K of them being
webserver.. Hyves (a dutch social network) at some point explained about 1 in
4 servers was webserver. The rest was storage, db, caching, proxys, chat,
whatnot.

------
genieyclo
If you're going to follow their line of thinking to its eventual end, then why
not urge Facebook to just write everything in Assembly? :)

------
damienkatz
Coding in PHP make Al Gore cry.

~~~
gaius
But Al Gore invented PHP!

