11 ms·

Making Facebook 2x Faster

36 points by wayne 17y ago

axod 17y ago
interesting article, but faster is only useful when everything works. I'd much rather a real concentrated effort on getting rid of the constant errors that popup on facebook. "Oops! something went wrong", "chat not available at this time", etc.
- glhaynes 17y ago
  I went months without having any significant problems... was really happy with their reliability. But for about the last month it's been really bad. It feels like I'm on their beta site or something.
paraschopra 17y ago
Unrelated but just have a look at the comments in that post. It is hilarious because almost every comment says the site has become slow. Engineers measures load time their own way; users experience load time their own way.
- thamer 17y ago
  Some of them complain that the site is slow in the sense that their friends' activities are pushed to their timeline a few minutes after they've happened instead of instantly. Not exactly the kind of performance problem the front-end engineers had in mind, I'm sure. How are all these people “fans” of Engineering at Facebook?
  - sgk284 17y ago
    Yea, I became a fan of FB engineering hoping to talk about their distributed systems and what not. Turns out well over 99% of the fans are simply there to complain about something on facebook thinking an engineer will fix it. None of them know anything about technology and are often complaining about apps that facebook has nothing to do with. It's a shame. Could have been a cool group.
    - Psyonic 17y ago
      It'd be nice if a group like that could have a simple admission test. I'm not trying to exclude people that are actually interested, but something really simple just to keep out the whiners could be useful.
jrnkntl 17y ago
"We noticed that a relatively small set of functionality could be used to build a large portion of our features yet we were implementing them in similar-but-different ways." Wait, what? They didn't do OOP in JS?
- eru 17y ago
  What does OOP have to do with it? Not all libraries in javascript have to be OOP.
cookiecaper 17y ago
It's good to make things faster, but their method of fixing it by "writing a library" instead of just rewriting the same functions over and over again is really, really basic. It really took them that long to do that? And once again, Facebook creates a completely custom solution for no real reason. They don't see any advantage in basing this off of jQuery or similar if they're rewriting the JavaScript anyway? Are we supposed to be impressed here?
- axod 17y ago
  I'm not being nasty or anything, but if you're aiming for speed, using a general purpose library like jQuery isn't what you should be doing. Writing the js properly optimized to the specific use case is what should be done.
  - cookiecaper 17y ago
    You're assuming that jQuery isn't fast. In my opinion, especially with something like JavaScript, one of the main reasons one builds upon a library is that the library's functions are faster than one could make independently. jQuery is concerned with speed as far as I'm aware; I see benchmarks for it somewhat often, anyway, and I know it's used at a lot of big sites who are also very concerned with speed and load time and therefore has had a lot of iteration and testing with what methods work best. Of course, if Facebook tested jQuery and found it too slow for their needs, that's all fine and good, but somehow I doubt they have. If there is a specific function that's too slow, there's no reason you can't improve or rewrite that function specifically and keep the rest of the benefits of the library. I just doubt that Facebook came up with something faster out of the blue. In some cases, it is true that highly-optimized and specific code is necessary to get maximal performance. Those cases are relatively few, I think, and usually involve code much lower level than JavaScript. In the case of JS, the code should be optimized to perform optimally across all of the major JS VMs. This sounds to me like something that jQuery's authors would have familiarity with, as they spend all day working on that. jQuery is not an abstraction or extra layer of cruft to bog things down, jQuery is a general-purpose library. It's not like an ORM or a dynamic language that adds a whole new abstraction that didn't exist before. Yes, ORMs and/or dynamic languages are slower, but they're slower because they obscure a major functional piece that still has to be performed (mapping onto the appropriate SQL dialect and memory management, respectively) by the computer. In this case, yes, a human could usually make a better choice than a computer if that human was adequately informed. jQuery is not like that. jQuery is not an abstraction, it doesn't abstract away any major task that the computer has assumed for you. It's just a fast library of commonly-used functions and building blocks. It's frequently tested against new browser releases for compatibility and speed. It's frequently optimized and improved upon. There is a huge community out there on tap for support and there are a lot of plugins for it. It's open-source and easy to modify if your case requires it. There are lots of other people from other places that are making important and great changes to that base at no cost whatsoever to you or your company, changes that you can apply just by installing the new version (in backward-compatible releases, naturally) and magically enjoying this speed boost that some other guy provided your website. I don't see any reason not to use a good open-source JavaScript library. We've used jQuery in this example, but I'm sure it's applicable to many others. I don't understand any business reason why Facebook would want to write something completely from scratch when there are these many frameworks already available. The only reason that I can see why this would be implemented in this way is either developer indulgence or developer ignorance.
toolate 17y ago
The big_pipe used on the homepage is quite cool. The initial request just returns <script> blocks as each partial is rendered. I wonder how they work it on the server side - they use PHP so they're not using any kind of threading. Perhaps the initial PHP request passes off most of the heavy lifting to their backend services over asynchronous Thrift calls. If that's the case then their PHP layer wouldn't be doing too much work, which doesn't seem to really tie in with them releasing HPHP.

36 points by wayne 17y ago

axod 17y ago

interesting article, but faster is only useful when everything works. I'd much rather a real concentrated effort on getting rid of the constant errors that popup on facebook. "Oops! something went wrong", "chat not available at this time", etc.

glhaynes 17y ago
I went months without having any significant problems... was really happy with their reliability. But for about the last month it's been really bad. It feels like I'm on their beta site or something.

paraschopra 17y ago

Unrelated but just have a look at the comments in that post. It is hilarious because almost every comment says the site has become slow. Engineers measures load time their own way; users experience load time their own way.

thamer 17y ago
Some of them complain that the site is slow in the sense that their friends' activities are pushed to their timeline a few minutes after they've happened instead of instantly. Not exactly the kind of performance problem the front-end engineers had in mind, I'm sure. How are all these people “fans” of Engineering at Facebook?
- sgk284 17y ago
  Yea, I became a fan of FB engineering hoping to talk about their distributed systems and what not. Turns out well over 99% of the fans are simply there to complain about something on facebook thinking an engineer will fix it. None of them know anything about technology and are often complaining about apps that facebook has nothing to do with. It's a shame. Could have been a cool group.
  - Psyonic 17y ago
    It'd be nice if a group like that could have a simple admission test. I'm not trying to exclude people that are actually interested, but something really simple just to keep out the whiners could be useful.

jrnkntl 17y ago

"We noticed that a relatively small set of functionality could be used to build a large portion of our features yet we were implementing them in similar-but-different ways." Wait, what? They didn't do OOP in JS?

eru 17y ago
What does OOP have to do with it? Not all libraries in javascript have to be OOP.

cookiecaper 17y ago

It's good to make things faster, but their method of fixing it by "writing a library" instead of just rewriting the same functions over and over again is really, really basic. It really took them that long to do that? And once again, Facebook creates a completely custom solution for no real reason. They don't see any advantage in basing this off of jQuery or similar if they're rewriting the JavaScript anyway? Are we supposed to be impressed here?

axod 17y ago
I'm not being nasty or anything, but if you're aiming for speed, using a general purpose library like jQuery isn't what you should be doing. Writing the js properly optimized to the specific use case is what should be done.
- cookiecaper 17y ago
  You're assuming that jQuery isn't fast. In my opinion, especially with something like JavaScript, one of the main reasons one builds upon a library is that the library's functions are faster than one could make independently. jQuery is concerned with speed as far as I'm aware; I see benchmarks for it somewhat often, anyway, and I know it's used at a lot of big sites who are also very concerned with speed and load time and therefore has had a lot of iteration and testing with what methods work best. Of course, if Facebook tested jQuery and found it too slow for their needs, that's all fine and good, but somehow I doubt they have. If there is a specific function that's too slow, there's no reason you can't improve or rewrite that function specifically and keep the rest of the benefits of the library. I just doubt that Facebook came up with something faster out of the blue. In some cases, it is true that highly-optimized and specific code is necessary to get maximal performance. Those cases are relatively few, I think, and usually involve code much lower level than JavaScript. In the case of JS, the code should be optimized to perform optimally across all of the major JS VMs. This sounds to me like something that jQuery's authors would have familiarity with, as they spend all day working on that. jQuery is not an abstraction or extra layer of cruft to bog things down, jQuery is a general-purpose library. It's not like an ORM or a dynamic language that adds a whole new abstraction that didn't exist before. Yes, ORMs and/or dynamic languages are slower, but they're slower because they obscure a major functional piece that still has to be performed (mapping onto the appropriate SQL dialect and memory management, respectively) by the computer. In this case, yes, a human could usually make a better choice than a computer if that human was adequately informed. jQuery is not like that. jQuery is not an abstraction, it doesn't abstract away any major task that the computer has assumed for you. It's just a fast library of commonly-used functions and building blocks. It's frequently tested against new browser releases for compatibility and speed. It's frequently optimized and improved upon. There is a huge community out there on tap for support and there are a lot of plugins for it. It's open-source and easy to modify if your case requires it. There are lots of other people from other places that are making important and great changes to that base at no cost whatsoever to you or your company, changes that you can apply just by installing the new version (in backward-compatible releases, naturally) and magically enjoying this speed boost that some other guy provided your website. I don't see any reason not to use a good open-source JavaScript library. We've used jQuery in this example, but I'm sure it's applicable to many others. I don't understand any business reason why Facebook would want to write something completely from scratch when there are these many frameworks already available. The only reason that I can see why this would be implemented in this way is either developer indulgence or developer ignorance.

toolate 17y ago

The big_pipe used on the homepage is quite cool. The initial request just returns <script> blocks as each partial is rendered. I wonder how they work it on the server side - they use PHP so they're not using any kind of threading. Perhaps the initial PHP request passes off most of the heavy lifting to their backend services over asynchronous Thrift calls. If that's the case then their PHP layer wouldn't be doing too much work, which doesn't seem to really tie in with them releasing HPHP.