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

7 Years Of YouTube Scalability Lessons In 30 Minutes

highscalability.com

Post reply on HN
Print view View original

21–30 of 77 posts

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#21

Post by m0th87 »

ajross wrote: post #19
simonw wrote: post #14

Earlier quoted context omitted.

Is RPC an actual technology? I thought it was more of a protocol design pattern.

Remote Procedure Call is a design paradigm for synchronous call-and-response network communication. The Sun RPC protocol is an actual technology defined in RFC1057: http://www.ietf.org/rfc/rfc1057.txt It's not insane, though not terribly relevant in the modern world. The only common technology still using it is NFS.

If you look at the original RPC work by Bruce Nelson [1], it's pretty clear that there's no strict definition of it. I think most would argue that SOAP would be included, which is still pretty common.

1: http://nd.edu/~dthain/courses/cse598z/fall2004/papers/birrel...

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#22

Post by tav »

old-gregg wrote: post #18
simonw wrote: post #14

Earlier quoted context omitted.

Is RPC an actual technology? I thought it was more of a protocol design pattern.

man callrpc

When Youtube refers to Vitess as being RPC-based, they are not referring to Sun RPC (callrpc), but rather to the generic design pattern of exposing service calls over the network. In particular, Vitess makes services callable [-] using either BSON or JSON serialisation over HTTP CONNECT calls.

[-] http://code.google.com/p/vitess/source/browse/go/rpcwrap/

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#24

Post by davnola »

ajross wrote: post #20

Most of this is relatively straightforward and unsurprising. But the one part that grabbed me is about "jittering". They insert random delays into timed events (the example given is cache expiration) to prevent a thundering herd problem when all the parts of the distributed system see the event at the same time (and for popular content, presumably repopulate the cache from the backend simulteously). This is simple en…

I've heard it called "splay" before e.g. `chef-client` will take an interval option and a splay option. Splay is a random amount of time added to the interval to prevent thundering herds.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#25

Post by minimax »

ajross wrote: post #20

Most of this is relatively straightforward and unsurprising. But the one part that grabbed me is about "jittering". They insert random delays into timed events (the example given is cache expiration) to prevent a thundering herd problem when all the parts of the distributed system see the event at the same time (and for popular content, presumably repopulate the cache from the backend simulteously). This is simple en…

I hadn't thought about it in the general case, but I do frequently find myself adding a sleep for PID mod some appropriate constant to the beginning of big distributed batch jobs in order to keep shared resources (NFS, database, etc) from getting hammered all at once.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#26

Post by hendzen »

"They wrote their own BSON implementation which is 10-15 times faster than the one you can download."

Curious to hear more about that one. If true, I hope they open source it, because that could potentially make MongoDB a lot faster for everyone.

EDIT: It's apparently in their vitess code. Relevant code: http://code.google.com/p/vitess/source/browse/#hg%2Fgo%2Fbso...

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#27

Post by tricolon »

mattdeboard wrote: post #6

The first 10 minutes are about monetization from one of the Youtube dev advocates. Skip to 9:45 to get to the "good stuff". As an aside, this fellow is probably one of the best presenters I've seen from the pycon videos for this year. Confident, smooth, not reading from a computer screen or sheet of paper, clearly smart and in firm command of the subject matter. I'd love to see more talks from him.

Wadsworth to the rescue! http://www.youtube.com/watch?v=G-lGCC4KKok&wadsworth=1

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#28

Post by ajross »

m0th87 wrote: post #21
ajross wrote: post #19

Earlier quoted context omitted.

Remote Procedure Call is a design paradigm for synchronous call-and-response network communication. The Sun RPC protocol is an actual technology defined in RFC1057: http://www.ietf.org/rfc/rfc1057.txt It's not insane, though not terribly relevant in the modern world. The only common technology still using it is NFS.

If you look at the original RPC work by Bruce Nelson [1], it's pretty clear that there's no strict definition of it. I think most would argue that SOAP would be included, which is still pretty common. 1: http://nd.edu/~dthain/courses/cse598z/fall2004/papers/birrel...

No, that's the ambiguity I was addressing. RPC means two things. The protocol is used, for the most part, only by NFS. The concept is pervasive.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#29

Post by [deleted] »

hendzen wrote: post #26

"They wrote their own BSON implementation which is 10-15 times faster than the one you can download." Curious to hear more about that one. If true, I hope they open source it, because that could potentially make MongoDB a lot faster for everyone. EDIT: It's apparently in their vitess code. Relevant code: http://code.google.com/p/vitess/source/browse/#hg%2Fgo%2Fbso...

[deleted]

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#30

Post by peterwwillis »

ajross wrote: post #20

Most of this is relatively straightforward and unsurprising. But the one part that grabbed me is about "jittering". They insert random delays into timed events (the example given is cache expiration) to prevent a thundering herd problem when all the parts of the distributed system see the event at the same time (and for popular content, presumably repopulate the cache from the backend simulteously). This is simple en…

In the past i've seen jitter used in all sorts of applications, from cron jobs to configuration management to memcache key expiration. Any time you have a crapload of nodes that all need to do an operation at a specific time you rely on jitter to keep resources from bottlenecking. Probably used anywhere the systems or network has a miniscule amount of resource headroom (like cluster nodes that run at 93% utilization)
Post reply on HN