Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
hello everyone thank you so much for coming I know it's a beautiful Montreal day outside and the snow is melted but thank you for coming into this room it's my pleasure to introduce Jesse Davis and his talk on what is a Seng how does it work and when
should I use it a round of applause plays hi everybody thanks so this talk is going to be something more like what is a sync when should I use it and how does it work or perhaps a different ordering of that the talk itself will be sort of asynchronous so oh
you guys liked that so my name is Jesse Davis I work for MongoDB in New York City and as you probably know in New York we eat three kinds of food we eat submarine sandwiches pizza by the slice and omakase which is a Japanese word for something like you go
ahead and choose it's when you go to a sushi restaurant and they just give you whatever is good that day so New York is a crowded place and each of these kinds of food has a different bottleneck as at rest to scale out to a very large number of clients
for example with submarine sandwiches it starts off you go to the counter and a sandwich maker comes out of the sandwich maker pool and you tell the sandwich maker what kind of sandwich you want what kind of bread what kind of ingredients and you have this
one-on-one synchronous interaction that lasts for the duration of your request so until the sandwich is complete the sandwich maker doesn't take a break doesn't talk to different clients that sandwich maker is devoted to you until the sandwich is complete
and you walk away with it at that point the sandwich maker returns to the sandwich maker pool until another client pop off of the eater queue so the analogy that I'm making here is for a cpu-bound web service something that might cryptographically sign
your request or something like that in that case you can scale out by either making the sandwich maker faster by say arranging the ingredients more efficiently or you might add more sandwich makers until the space behind the counter is full so this is like
you can add faster CPUs or you can add more processes until you have as many processes as you have cores but that's it you don't want concurrency here it wouldn't make sense for the sandwich maker to be switching between different clients and trying
to make multiple sandwiches at once so this is like a CPU bound web service that doesn't request any external assets in order to satisfy a client request there's no need for async here each process should just handle a single client request at a time
from start to finish without doing any context switches so this is when not to use async don't use async for subs but different kinds of food have different scaling properties so what about pizza it starts the same as subs you go in and the pizza cook
appears and you ask the cook for a particular slice of pizza the slices are already made but there's sort of lukewarm so the cook takes your slice and puts it in the oven and for the two minutes it takes for the slice to heat up you're both standing
around idling until the slice is hot the cook gives you your slice and you walk away with it so in this case how do you scale out the pizza cook how do you deal with multiple clients showing out there once here you wouldn't want the pizza cook to act like
a sandwich maker you don't want the cook to address a single client and then stand around idly for two minutes until the slice is hot then give it to that client and then ask the next client hey what kind of slice do you want if you had to devote a single
pizza cook to each client you would run out of space behind the counter before you run out of space behind the oven so the analogy that I'm trying to make here is I'm trying to say that the cook ought to be async the cook should respond to events as
they occur so as clients arrive the cook asks each one what kind of slice do they want and as slices become hot in the oven the quick response to that event and gives the hot slice to the client and in that way one or a couple cooks should be able to serve
a very large number of concurrent clients now the one problem that the cook is going to experience is that with lots of concurrent clients all asking for slices and lots of slices in the oven the cook is not going to need some kind of mnemonic for remembering
how long each slice has been in and what client it belongs to so this is sort of like a regular old web service that has a big slow back-end like a database or an OAuth provider here async is a great idea for scaling because a couple of processes can handle
a large number of clients with many concurrent IO operations but you're going to need some way to store state while each operation is in flight the same as the cook needs to remember which slice goes to which client and how long it's been in the oven
now this is even more true of omakase or actually I just learned that it's probably pronounced oh macha say but anyway the way it works is you and your friends you all go up to the counter and the waiter tells the kitchen a bunch of people arrived and
that's it the kitchen starts making sushi whatever is good that day and as the sushi becomes complete the waiter ferries each dish to the clients at the counter once again you don't want a waiter devoted to each client because you'll run out of
space behind the counter instead you should have one waiter or a small number of waiters who are event-driven who notice clients arriving and notice sushi becoming ready and are able to multitask and scale out that way up to the limits of the kitchens ability
to produce sushi and this is like a WebSocket newfangled application where clients connect over WebSockets and await server-side events so if you log into Gmail for example your browser opens a WebSocket connection to one of Google's servers and then nothing
happens the connection remains idle until a new email arrives for you on the server and then the server notifies you over the WebSocket connection and your browser updates itself if Google's servers were to devote a thread for every client connection they
would quickly be overwhelmed by the number of threads that they had to support because WebSocket connections are very long-lived so there's a very large number of them concurrently for WebSocket applications in particular it's critical to minimize
the resources devoted to idle connections so this is what async is for it minimizes resources per idle connection while you're waiting for some event to occur and the main resource that you need to conserve is memory so we typically say that asynchronous
Asians are not CPU limited but memory bound and that the challenge is to store per connection state as efficiently as possible the influential paper on this topic is called C 10k it's by a guy named Dan Kegel or Kegel and the paper is about 8 or 10 years
[ ... ]
Nota: se han omitido las otras 3.407 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.