PHP too slow for Facebook, builds its own faster version

While I will say that there are all sorts of solutions out on the net, I can't say that this is PHP's fault as much as the developer's fault.

Don't get me wrong, I realize that Facebook is perhaps the *largest* social networking site on the internet. However, they still have developers who run the schemas that this website is generated off of. I've also seen Facebook's runtime model they use for publishing their pages, but I personally think it's their model that is flawed.

They make way too many requests, and the manner in which they deliver their content is not optimal. But the fact remains that companies end up out-growing languages they used to initially get their name out on the block, just as Google wrote their own versions that could better server their own personal needs.

I've said this many times, and I'll say it again: It isn't the language that holds a company, website, or arch. back, it's the developers themsevles. One can only do what one understands from a language. Had this been .NET, Ruby, Python, Perl, etc, you would probably be hearing the exact same thing happening again, and this is mainly because they have found that the model they built their framework around isn't working at the optimal speed.

But for the author to say "was simply amazed that Facebook has been running interpreted PHP all this time -- it's definitely not the fastest (or prettiest) language in the west.", it just goes to show this author's misunderstanding of PHP or any other language for that matter.

PHP is not the fastest, it's not the prettiest, but no language truly is either. It's only as FAST and PRETTY as the developer him/herself makes it! Not what fanboys say is faster or prettier.

+1 on that!

I can't seem to get PHP to run on my facebook page. :(

I never said I was smarter than the developers at Facebook. I do, however, stand by point that it's at the developer's code that speed is affected.

Any developer will tell you that when working, no matter if it's Facebook or Joe's Supermarket, when you work for a fast-paced company, they want solutions fast. They want them fast because that's what their audience calls for. But when we write the code fast, we sometimes make quick solutions rather than optimal solutions. And we end up saying "we'll fix this after we publish it. we'll make it faster!"...but that day doesn't come. And since our solutions "work", our bosses don't want to give us the time to make the necessary optimization changes that we, the developers, see and know need to be done.

But that happens everywhere, every day. If facebook held off on production of any other new features, could their developers find a faster way? OF course they could! That's why they went from being an ASP shop to being a PHP shop, because they gave them that time.

Either way, they're doing it again, except this time someone said "we should just build our own logic that adheres to own companies needs, not rely on a language that is meant for everyone. it's not personal enough to do what only we need". And that's what happens, even at google. it's part of evolving. I wish them luck.

I've never experienced Facebook as slow when browsing, but then it might be because I -only- have about 70 friends (real IRL friends, mind you) and I tend to block all those tiny little pointless applications that doesn't enhance the Facebook experience, but tend to spam your live feed.

And seriously, what's the deal with every single person accepting every friend request? People's definition of "friend" is rather weak when you have like about 90 % of your "friend" list populated with people you only met once or twice.

Oh, and the post was a good read! I didn't know Facebook ran on PHP before.

As much as I hate PHP, If their PHP code is anything like their Javascript code, I don't think PHP is entirely to blame here.

A small clarification so that people who are reading this who don't know much about PHP have all the info.

Although PHP does not cache compiled files by default, I would be extremely surprised if there are any large websites out there running PHP that do not use eAccelerator, APC, or some other op-code caching extension.
Using either of those tools will cause the compiled versions of the PHP script to be stored on the system the first time it is accessed. From that point forward the compiled version will be used instead. Which is, needless to say, much faster. To say that PHP is always compiled or interpreted on every page load would be absolutely false. Incidentally, both those tools take about 20 minutes (or less) to install and configure.

If Facebook built a tool to do that then they are simply reinventing the wheel and instead should be contributing to the projects already out there. But I'm sure that they know that already. So what they are actually doing will be interesting to see.

One thing has to be clear: if PHP is "slow" to them, they are coding it wrong!

But if they think they can do better, they can always opt-out of php and create their own cgi-alike executable thingy to handle their requests.

Just my 2 cents... giving you a cherry to top it off: facebook has one of the worse codebases in the history of the internet. Maybe they should clean up their act before trying to imply that it's php. Bah, next they'll say it's their mySQL or what? * LOL *