Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Google makes Google(+) fast

plus.google.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: How Google makes Google(+) fast

#21

Post by archangel_one »

georgemcbay wrote: post #2

Google+ is certainly fast, I just wish it were quicker about showing me valid/updated state. I've never used any website where the data I was seeing was so obviously out of date across the board as it is on Google+. Yes, eventually it coalesces towards correctness, but I don't think this model works well for things like notifications and such. "Oh look I have a new notification... oh wait, no I don't, that's from lik…

I agree with the notification problem, although I don't think it's to do with caching local state; it just doesn't seem to register that the notification has been seen until I actually click on the red square. It's more annoying than I would have thought, really.

Facebook has the same problem, of course; they have some increasing counter which seems to tell me nothing useful at all.

Re: How Google makes Google(+) fast

#22

Post by archangel_one »

I'm rather more grateful for all the work Google have done here after using Diaspora; the one thing that nags me about that more than anything is how much slower than G+ or Facebook it is. A couple of seconds on each click really breaks the whole experience.

Re: How Google makes Google(+) fast

#23

Post by bad_user »

vl wrote: post #14
shantanubala wrote: post #4

Earlier quoted context omitted.

Facebook is pretty amazing in that respect. They managed to engineer a scaleable infrastructure without making it too obvious that everything is being cached. There are times when it takes a minute or two for my profile picture to change everywhere after I change it in my profile, but aside from minute-or-two scenarios, Facebook's interface (and the real-time notification system) is just amazing in comparison.

Facebook runs largest memcached cluster in the world and largest sharded MySQL installation in the world (which they use as a key-value store since it's hard to evolve schema otherwise). So, essentially, quick updates are tremendous amount of duct tape and hand-crafted code to make it work more or less correctly.

I've always wondered why alternative datastores, like MongoDB, get so much good press when a RDBMS like MySQL or PostgreSQL can be used for storing non-relational data in a way that scales tremendously.

The only article I'm seeing for this issue is this one from 2009, by Bret Taylor: http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Other than that, crickets, which is a shame as these RDBMS databases are proven to be more reliable than the fad du-jour.

Re: How Google makes Google(+) fast

#24

Post by bad_user »

harlowja wrote: post #16
shantanubala wrote: post #4

Earlier quoted context omitted.

Facebook is pretty amazing in that respect. They managed to engineer a scaleable infrastructure without making it too obvious that everything is being cached. There are times when it takes a minute or two for my profile picture to change everywhere after I change it in my profile, but aside from minute-or-two scenarios, Facebook's interface (and the real-time notification system) is just amazing in comparison.

Relevant: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse... I'm not so sure that using mysql at this scale is in the end such a good decision...

Considering the unprecedented scale they are operating on, their track record is not too shabby and because of that I would take any opinions to the contrary with a big grain of salt. Also, that article is filled with hyperbole and meaningless words, with sentences that contradict each other. In one place he's are saying ...

    MySQL ... wasn’t built for webscale applications
But in another he's are saying ...

    Facebook has split its MySQL database into 
    4,000 shards
Well, if the author had any clue whatsoever, he would know that splitting a database in multiple shards effectively goes against the relational model (Facebook is effectively using MySQL as a storage engine, not as a RDBMS) and so inherent limitations that make people say MySQL wasn't built for webscale applications ... no longer apply.

     SQL databases ... consume too many resources for
     overhead tasks (e.g., maintaining ACID compliance
     and handling multithreading)
Again, ACID compliance and multithreading becomes a local issue, relevant for a single shard. ACID compliance does not apply to the whole cluster of shards they have and it is still freakishly useful, even if applied locally, because you want the guarantee that the user's submission has been saved somewhere in a consistent state, from which you can safely replicate.

At their scale maybe they could have chosen something better, more suitable to their needs, however the question is ... how can you make a choice when nobody else has dealt before with a social network handling submissions from hundreds of millions of users and that's expected to reach 1 billion?

You can't. On the other hand it is easy to blabber about webscale (WTF does that mean anyway?)

PS: I'm not going against the opinion of the great Michael Stonebraker, but he's not the author of the article and his views must be taken in context ;) He's not wrong to say that MySQL will be problematic to Facebook. What I'm saying here is that MySQL was as good as any other available alternatives, especially considering how Facebook uses it.

Re: How Google makes Google(+) fast

#25

Post by gizzlon »

alexgartrell wrote: post #13
georgemcbay wrote: post #2

Google+ is certainly fast, I just wish it were quicker about showing me valid/updated state. I've never used any website where the data I was seeing was so obviously out of date across the board as it is on Google+. Yes, eventually it coalesces towards correctness, but I don't think this model works well for things like notifications and such. "Oh look I have a new notification... oh wait, no I don't, that's from lik…

That's because most distributed data stores are eventually consistent. This works fabulously in a world where data needs to exist in a handful of places (say, a user's email inbox, which should be replicated so it can be accessed quickly from different geographical areas and for the sake of disaster recovery) but need not necessarily all agree with each other at the same time (If I send you an email, it's OK if you d…

Guess fb updates the users UI right away and lets the change propagate "eventually"?

Seems like a good idea, and in my experience most "normal people" think fb is instant.

Re: How Google makes Google(+) fast

#27

Post by cosgroveb »

piranha wrote: post #17
cosgroveb wrote: post #12

Earlier quoted context omitted.

Google Closure Tools is not the same thing as Clojure. A little confusing I am sure since Closure Templates is a templating system that dynamically generates HTML in Java and JavaScript... And Clojure is a language that targets the JVM. I have no experience with Closure Tools but Clojure is awesome definitely.

ClojureScript uses Closure Tools: https://github.com/clojure/clojurescript/wiki/Google-Closure

Either the author of the comment I replied to ninja edited his comment or I need to work on my reading comprehension. I think it was the first thing though...

Re: How Google makes Google(+) fast

#28

Post by oinksoft »

dmix wrote: post #6

Are people outside of Google using closure to develop apps? I used the closure compiler with Jammit but I've never tried the library.

Many people are using it, they're just not the types writing "10 Great Form Validation Plugins for jQuery" posts, so it might not seem like it. The same can be said of Dojo, but in my opinion Closure is Dojo done right.

Re: How Google makes Google(+) fast

#29

Post by Fizzer »

bad_user wrote: post #23
vl wrote: post #14

Earlier quoted context omitted.

Facebook runs largest memcached cluster in the world and largest sharded MySQL installation in the world (which they use as a key-value store since it's hard to evolve schema otherwise). So, essentially, quick updates are tremendous amount of duct tape and hand-crafted code to make it work more or less correctly.

I've always wondered why alternative datastores, like MongoDB, get so much good press when a RDBMS like MySQL or PostgreSQL can be used for storing non-relational data in a way that scales tremendously. The only article I'm seeing for this issue is this one from 2009, by Bret Taylor: http://bret.appspot.com/entry/how-friendfeed-uses-mysql Other than that, crickets, which is a shame as these RDBMS databases are proven…

There's a video (I don't have the link handy) where a Facebook engineer says they actually had to make code modifications to MySQL to make it do what they want.

They're using the tool in a way that it wasn't designed to be used. Therefore it's probable that that there's an opportunity for specialized software to fill the role better.

Re: How Google makes Google(+) fast

#30

Post by youngtaff »

gvido wrote: post #20
coderdude wrote: post #19

"On a side note, you may have noticed that we load our CSS via a XHR instead of a style tag - that is not for optimization reasons, that’s because we hit Internet Explorer’s max CSS selector limit per stylesheet!" Can anyone go into more detail about what they're talking about here? I didn't realize IE had a "CSS selector limit." Seems like a funny thing to mention when you're talking about how optimized your site is…

Yes, the magic number is 4095 selectors. And it's still true, even in IE9.

Do they really need that many selectors - it can't be good for performance?
Post reply on HN