Merken

Don't Forget the Network: Your App is Slower Than You Think

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and the end of the 2nd transferred that you're going to I thought they that's very kind and generous you to listen to me talk to you about things the my my time is called I don't get the network you have slower than you think I'm going to talk about I guess things that you probably haven't thought about yet it's about how people use your application and about ways that people using your application are having a worse time than you think that they are and so I think keys I'm I don't really know any good way to talk about this except by probably making you feel bad for your users and so brace yourselves and you'll be fine but before I get to that introduce
myself when it's on the Arco and indirect almost all the things that me that now that I'm looking at that's 1 of the top all I'm sorry expected summit post the slides and speaker that I wrote a
book called review way all the 3rd edition I co-authored with the of the and it's actually pretty great ever read from the very 1st edition of way and it was my favorite book except that I couldn't tell anyone to use it because it was about review 1 . 8 and so I updated in a coverage of the 2 . 2 and 2 . 3 and if you buy it a in a couple years you can use it to properly monitor and tireless you might have not been part of the review and 2nd lecture but I really can't see
development we do the mobile and web application development from scratch but mostly what I do is join teams that need someone to really see here to help with their rail that were the front and add some of them are members of and I guess if listening to this talk makes you feel like you could use someone to help you feel less bad talk to me later that is literally my job yeah I I work on something else you may have heard of
problem where I it's I mean I work a moment for a long time but it's been a really great experience work on open source and the kind of interact with every aspect of the every community people do things with but that I would never in a million years imagined that people do really and then I get to help them all the profits of and so we put a lot of effort into making it I guess easier and all that easy but easier to get started contributing to open source through bond a lot of other open-source projects and if you're interested in majoring open-source definitely talk to me later between me and I would love to help you start contributing open source on the last
thing that I spend time doing is called meeting on shirt and Ruby together is a nonprofit trade association for Ruby people and companies that pays developers to work on the and on regions so that you all can unbeknownst all and it actually works at and without companies and people giving us money it like regions are just wouldn't stay up and you would be able to buy nonstop because that's separately we have to work on it every week to keep it up its servers itself where it all breaks all the time and that the only reason that were able to keep it working another there are so many people using Ruby and using revisions is because companies like straight and base camp and heroic and every and we are willing to give us money so that we can pay developers to make sure that all works on the haven't let regions that or go down in the last year which is super great but at the rate usage is going up we need more people to give us money but if you are a manager or if you can talk your manager about remain together that would be up so the network and how at
a slow and think and I guess routing is a thing that your app hats and even if you didn't think that it does so I guess at 1 point there was a very widely shared article on rat geniuses blog about how brokers rather with a sham and everything was awful I guess unfortunately whether you're group who were not you have as a router and it's probably making things worse than you think they are so let's talk about how that is and why that is and what you can do about it on so routing what I mean is the part of your worst applications infrastructure that takes the request from the outside world and load balancers it or forwards it or like somehow get it through your infrastructure until it finally reaches your Rails app server and then you afterward that some stuff and tells you like a list of 45 ms and then it has to go back through the engine 4 each a proxy or an next energy proxy or whatever it is we use back to the outside internet and then across the entire outside that back to the user who was trying to find that thing out in the 1st place on so how how exactly does this work by maybe you haven't thought about this actually don't when you on your laptop this is a non-issue right in
development this running you you talk to your ass that's that's great actually so but unfortunately in
production you need more than 1 app server and people are coming from a lot of different places and so this is just like a generic rails not every real sample look like this but almost every real that looks like this you have some outside level load balancer you have some inside level here's how we split request up across all of the Unicorn they're all the nodes are all the whatever's on and every single 1 of those lines adds time to what your users see that you never solid were working on the program on on your left on so question time raise your hand if you know how long a writing where cakes that's what I I given this I asked this question in various different types of about 8 times ii a totally expected known to raise their hands literally had 1 person ever raise their hand 8 talks it's probably like uh I know closing in on a thousand people now and once scheme and ask this question added a lot conference and 0 people like I don't expect you know the answer to this question on but it's actually really important question to ask because your end users experience is 100 % directly impacted by this like someone who goes to your production at and tries to use it experience 100 per cent of your routing layer twice for every request that they make and like is a long time who knows none of us and then on on on top of that like so not only is there this question of like how long does it take in a perfect case from like the time they make the request to the time your average processing it and then from the time at stops processing into the time they get the response like none of that time shows up in your nice new relic grass that's like how long this took like 0 of those MS are included in that number and so you can look at the number and the like you have we answer all requests in I don't know what a good rails the number 2 and 50 ms feeling that to become more but like how much time you need add to that before you know how much a user actually experiencing on how do even find out and then once you find out what if too many requests come in exactly the same time just having that routing layer where all of your requests come to 1 point and they fan out across other points this was like the main point of that wrapping his article was that broken uses of and honestly like there's nothing else that you can really do that makes sense you just kind of randomly assign like well here's 1 for you here's 1 for you don't and the problem is almost all Rails apps have like some requests that take 10 milliseconds and some requests that take like 2nd half and when you're just throwing them out at random to every server that can possibly service then unfortunately statistically it is very likely that you will end up with 2 horribly slow request factor behind each other and then the really fast request to stack up behind those and it isn't very long before you might see a 30 seconds time you like that makes sense that request new says that request takes 10 ms why would it had a 30 second broken entirely on and so it's not perfect but you can at least starts to get a little bit of visibility into this using a new relic feature called I Q track where you have the load balancer set header that says I got this request at this exact time and then your app services will I didn't get this request until this much later time and then you wrote and added thing to your graph that says well you your request is spending about this much time just sitting around waiting for a server to have availability to answer the I ended that can be a completely separate thing that people don't matter that is adding 50 % sometimes seen that too like the total user waiting requests and the 2nd 1 even measured no 1 was happening which like that weird it seems to take a lot longer to get a response the new as it takes to make the response I wonder whether right and so so ultimately what I mean trying to impress on all of you all
is that the overall requests time is not the number that skylight heroic because service and only care tells you your request takes like that's a good number of measure that number pay attention to that number it that number changes a lot you wonder why that number changed a lot because that's the important but I don't think that that number means that that's how long people are taking to like get the results of your app running on don't write exactly but it's not the time that you measure that your app takes to run yeah at the end and honestly even that hewing track that I was talking about what new relic that requires that those clocks on the load balancer server and the movie app server be like synchronized so precisely that they can measure MS accurately and like it's very easy to end up with Cox milliseconds off and then your measurements are off and so we want instead is a wholistic measure of how long does it actually take to be a person on the internet say hey rails out I want to know a thing and then for the rail that to say OK you should thing and then it arrives back so the strategy that I've actually had a really successful here is to deliberately create a rails controller that returns an empty string and then set up a service like ones go or a thousand eyes for 1 of the Kingdom even likes their services whose entire reason for existence is so that you can make requests to your own stuff from all over the world and find out how much the way your overall infrastructure adds to your application and ends if you have a rail app that returns an empty string I just wanna sleep even you interact middleware that returns an empty string because you relic measures the like Rails framework over and right so you just wanna know about all the time up to the time it it's to react and all the time after comes out of you react and so you can use 1 of these monitoring services to say this is like the the weather report for are users around the world and I see that I worked at companies where like 60 per cent of the traffic was the US but for no particularly apparent reason 35 per cent of the traffic was from Brazil and make you really care a lot about network conditions changing and meaning that traffic to Brazil got a lot slower today you should figure out why that happened and maybe think about setting up a CD in Brazil only because like if you're traffic numbers are relevant to your business making money almost always are of this matters is huge amount and right now chances are good like nobody has any idea what they are are they bad we don't know what a great we don't have either maybe great like honestly if all of you go home today in start monitoring the numbers and the fantastic numbers I will be extremely happy for you to i based on past experience unfortunately they're probably not that great I but knowing what they are is way better than having no idea that they exist but very closely related 2 things taking longer than you think they do I'm sorry
about servers so I'm assuming that if you have things deployed on servers this seems like a good bet I I would say well what's happening on your servers other stuff right like you you buy the new rack them or you rents by a fraction of 1 or don't you you rent a fraction of a fraction of a virtual machine that is a fraction of a physical machine happens right that you end up with a piece of a computer and some stuff is happening on a computer and even if you bought the computer yourself and wrap it yourself it's still running a
ton of stuff and you have no idea what that stuff is and I'm not going to tell you that you need to know what all that stuff is what I am going to tell you that it's really important to know how that stuff is impacting the thing that you do care about which is your users and experience and so
a big thing the impacts this uh will you use Ruby or Python unloaded go you have a runtime for your application right like a even go has the garbage collector and a framework that although programs run inside and the what that means is your application sometimes is running while your program is running and when that happens your code is coming you're instrumentation is running and you have no idea how long that yeah yeah so if the garbage collector runs in your entire application the stops for a while the have you know that the have you know how long it's like you're you can write it's really hard to write code that measures time at your code wasn't allowed to run it on so that based on real world usage but definitely go and Java and Ruby all have like garbage collection pauses where like execution of your code just don't hang on wait started collecting garbage OK said you keep going and really I guess recently has added a thing called GC profile that at least reports after the fact how long garbage collection to which is often I but there are more reasons than just garbage collection your code could end up paused and so what you actually want is some way to say I can tell that might have stopped working stop running right it was still working but stop running for a 2nd and it started running again and how long was that and there's this island this checked from somebody who works at paper trail our but I think he got from some of his colleagues return of super cover what you do is you start a new thread with about me was like really specific but you can use any language you start a new thread and then you say what is this time sleep 1 what is the time and then you subtract them and use of the difference offers laughter of and if your code stops running sleep 1 will take longer than 1 2nd little known back and so by monitoring how much wall clock time passes well but thread in your application is calling sleep 1 you can accurately graph how much overhead the surrounding interpreter is adding to your overall execution time and I have definitely seen this happen where I like you're running a review program and you like continued it seems kind of slow and then you check the like how long does it take to sleep for a 2nd graph you like 0 my god Preston 150 ms doing something that's not running my program every 2nd and sometimes let me give a memory leak sometime that means like that machine got into a really bad weird state of but like everything you know and everything you know that it's exactly that it but back at server that having this problem and all the other parts of supply on super useful I guess very very closely related to this is
the virtual machine that you're another time that interval lad right you're probably also running that interpreter inside a virtual computer and Amazon Digital ocean pro group and our OpenStack your either running on a VM we're running on a VM inside of the and or maybe even if Doctor of the inside of the and inside of the BN parade of and as you can imagine that this is yet another way to have weird times where your code doesn't run and you don't actually know it because you can literally run on and it's even worse than that because sometimes you'll end up with resource specific intention right like in the and what if you're on a VM in 1 of your code tenants suddenly like your coat and it is running a memcached server and so it's just like all the memory I O is going to your coat and how do you even know if that's a problem what they're doing something really like a storage heavy and that means you can get I O and more and so there's like at a minimum the resources that you may care about our CPU and memory and that's right and network I O I guess we remember to that on the other side of and you don't know when you get a shiny new empty the like maybe everything's great and maybe that machine has basically no network I'll available or as basically no memory I O available because of code and the don't know exist on and so netflix has a really clever way to check for this I guess I they've been written about kind about length and with within of doing is that expense of the new E C 2 instance and then before deploying to it show a giant pile of benchmark suite onto it and they run the benchmark suites and they compare it to what they've decided is acceptable performance for that price point on E C 2 and if it's below the acceptable benchmarks they throw away that the amended UBM and try to benchmark we again and then from that 1 landing than anyone and eventually make it an instance that meets their like criteria may said in the paper that they have observed almost an order of magnitude difference in performance at the same price i'm because amazon sells both the newest generation of hardware and 2 or 3 or sometimes even for generations all as the same year very logical to them saying I'm in then you have to deal with like a tendency issues where you may have a VM on a very old very heavily contended physical machine you may have a VM on a brand new uncontested machine and my so for Netflix they said that doing this and I'm probably going at these exact numbers alongside that allows the cell to that paper they save something like a 3rd of the overall server costs by doing this benchmarking and only accepting the and that that the minimum criteria because of the amount like they have a static amount of traffic that they need to survive but they got machines that were more capable to do it at the same price yeah i'm and so they just needed to spin up less machines and the Amazon less money but I guess so you're probably not Netflix this probably doesn't matter to you that much on but it is at least something that you can be aware of when you're like me and 10 servers seem to be enough to service traffic last week right up and then specifically like do you know what it is that your app cares about like it is entirely possible that your application is in completely CPU-bound and you honestly don't even care if your code and into doing tons of I O I really care laughter considering you I mean it's them server and you're just memory I about maybe it's PostgreSQL and you're everything bounds because that's just want everything on the but like this is the kind of thing that actually matters and knowing this difference can be a really big difference in how many servers you need how much a service cost and as you get bigger and bigger like 1 3rd more performance for the same cost becomes a larger and larger number that is worth putting more and more effort and again getting a cell now that convince you that you need to measure all these things we were measuring before the start of match this of I
guess it's a good point about the review community they're pretty good at measuring metrics that's great new relic makes it really easy you gents on the relic grade and metrics on metrics are really important tracking things and we were just discussing is really the only way to know what's happening without metrics your production is kind of a black box and you're like 0 0 things are as good as they were before I don't know why or probably even how exactly because I wasn't measuring was able to measure did not a measure of the things that matter so as are really the 1st time that how important metrics are really all for me was in 2009 and get of source code cost sort of like a help metrics metrics everywhere and kind of the underlying point of his talk was that the reason that all of us have jobs and the reason that all of us write software used to deliver business value whether that's to our bosses or to customers for 2 clients Lake most of the software exists for the purpose of delivering business value especially if you're getting paid to write right and if you can't measure it you can tell if that is what you are doing so having said that you're probably not super
impressed by me telling you that metrics are important yeah I like right so you do need to know what's going on there is a catch once you
have metrics you have a tendency to become convinced that you now understand what it and I don't I don't blame you I do this too right it's like a human thing you like on measuring thing now I understand it so but just like being able to see the speedometer does not tell you how the cars transmission and engine work to be able to see a metric on your application does not tell you about how and why it is working it just tells you something is very different than it was before and now you need to figure out what it is and why it is different on an and a very common problem is that having metrics having some visibility makes people think that they have told visibility and that just is how things work portion fortunately and so at the end of this a little bit about metrics this
probably you instead of an aside about some way that metrics actively mislead you and of the biggest thing that causes this kind of like misunderstanding driven by metrics is
averages on when you have a lot of metric information especially if you have like a bunch of app servers the easiest way to like this still that down into something you can quickly communicate is to take the average super good example of this is the way that new relics dashboard we 1st open it it's like use a giant number this is the average of all requests across all app servers and so you see those graphs you see the numbers going up and down like great now I know what's happening with man right unfortunately not brains are really highly developed carefully tuned pattern matches this is how humans can see Jesus and toast this is how this is how you can see an average I think I know what that means so your brains immediate extrapolation from an average is probably what's called a normal distribution area
normal distribution so right you think 0 that average it's going to be right to talk that and this is often called a bell curve and it's what happens when all of the inputs into the graph are generated by a random function tell me if you think that your app is a random function I mean maybe it feels like it's a random function but we're at is not actually a random function and the practical upshot of that is that it doesn't look like this so a whole right leg this
is a more realistic graph of like what might be producing an average that's right at the 0 point on the graph on to kind of drive home how wildly misleading averages can be but let's look at a bunch of grasp at the same time so this
is a whole bunch of different measured metrics for real life thing it with my sequel benchmark doesn't really matter what it is of from left to right it's collecting the number over time so you know near the left it's like 1 of the things that work fast and then as you go to the right it's things that were slower and slower and slower during the benchmark and so the small black vertical lines that you may be can see very well represent average for that particular line so to make it easier to see on line up all the averages of the same graph so not only do
any none of these look like about right bell curve not single 1 is the set about yeah worse than that most of them have 0 actual data points at the average life of it's it's really characteristic have a very large number of points either clustered together in the fast zone or spread out over like a long tail of slow things like if you look down at the bottom the like some of these lines don't even have a single result that's near the average line and so if you're looking at new relic you might not even have any request that take the number with the amount of time that is the number of milliseconds bigger seeing in giant thought on the dashboard on this is the problem of averages
right unless you're metrics are being generated by a random function the average is going to actively mislead anyone can see this
on the great quote about this for tweet back the problem with averages you on average yeah everyone that is and so again averages I guess the single good thing that is really great about averages of that is that they can tell you that something changed right you can say 0 my average was this before but my averages this now that's weird the problem with averages is that they can't tell you what changed or how it changed and it's actually possible to
get that information out and so on the show you how to do that so well averages can tip you off that something changed of so here's a graph of an average and as you can see things are taking about less than 100 ms but that effectively means there could be tons of things happening that think about 100 ms where there could be tons of things happening that take 10 milliseconds and some the things happening that take 3 so it's it's an average so there's literally no way to know 1 way to get around this is to grab the median rather than the average on the median is the number that was bigger than half of the numbers and smaller than half of the numbers of the great thing about the median is that you were sure that it actually happened right of the average may or may not have ever actually happened that the median definitely and so if we add the median to this graph you can see on the purple line we now actually no more information than we did before most half of the values are actually very very fast it looks like a random the 10 millisecond range maybe 20 milliseconds so even though the average of all the way up to 150 msec at 1 point at least half of the requests were happening still equally quickly they slow down yeah that that tells us that since most of the requested and slow down this was like an application-wide change right we didn't suddenly get a really slow load balancer we didn't see we break this was a really a networks which problem where all the traffic was impact our the next thing you can do is graph other places the mean the median is the 50th percentile right passes below has about sir grabbing the 95th percentile 95 % was below 5 per cent was about here you can see that the slowest 5 per cent of requests got dramatically slower that of more than 10 % lower than the 10 % more than 10 times slower than the median and that's what drag the the average oftentimes even better than the 90 5th percentile in the 99th percentile this gives you a good idea of what 1 it's 1 out of 100 right so this is actually a pretty good indicator of what the occasional slow requests right well had to rescale the graph the and the slowest 1 per cent of requests for now clearly the entire reason why the average tripled the median state exactly the same as the median is not flat line but in that's lowest 1 per is probably some single specific controller action that you never need to go find and figure out what exactly happened to that specific single thing and so just by graphing but percentiles rather than average which immediately rule out about half of the possible problems that made our average slower and it works the other way around 2 if you if you look at the graph of the 99th percentile and it is dramatically different you know your average is higher then you know not to look for a single controller actually you know look for a systemic problem the aggregate graphs this is a recall another really common thing where aggregation is a fancy way to say I got that many versions of this metric for many servers and then average so here again here's an
average graph from this what happens to be taken from the actual number API of and it is a graph of the trick that I mentioned call sleep 1 of the you see how long it took so the number that were tracking here MS anywhere went from taking 2 milliseconds to you know 1 2nd plus 2 milliseconds to taking 1 2nd was 5 ms and that means that garbage collection pressure must have been twice as bad question mark we don't know this is an average on and you can you can improve this with breakout graphs
if you are collecting a number from 25 machines that 25 lines on the graph instead of 1 that will mislead you about what all the different machines are doing here's a break graph of the
same data I kind of like I was mentioning before with the break graph we can see holy crap this had to be rescaled 1 of the machines started taking 35 ms per 2nd to sleep but all the other issues basically 5 and so we went of resolving this issue by just killing 1 9 0 that was having trouble and restoring as a fresh final but we didn't have to do all of our diners we can have the right this narrow down the problem immediately just for having a break so doing the there
on here is an example of why visualizing the data is so so so important yeah so users in
different data sets but each orange doctors a single entry on that dataset I can anyone guess what the blue line its but but but but but the so that average so average the average paragraph but it's actually even worse than that the average of is exactly the same it's actually even worse than that all 4 data sets have the same average of X average of what variance of X. the variance of Y. correlation of x and correlation of otherwise in the same linear regression yeah actually grafted data and then look at it because the numbers of the averages and variances and the correlations than the linear regressions still contain any of the information about what is different in the on 1 kind of a lot of people that even talk to me about how awful averages are and then in like OK so how do you alerts work and a
lot of people have a words that are set up to the talk to them after the average is back it and as you can maybe guess by the time the average is bad it's
too late I definitely break
out your alerts as well as your graphs right you wanna win the 1st server when down not when the average of the servers is a downed server it right so
ultimately I really just wanted to let you guys know that the network is a part of your application most people don't think about it because they don't have to interact with it in their day-to-day development on a local machine and after you have deployed in your application is really user experience that matters not how many milliseconds you Ruby abstand running code that's it http after so the question was if you don't on averages how do you prevent continuously 0 learning getting a lot fatigue and then not noticing that something actually that what and the question included and note that there is no silver bullet for this and unfortunately the answer is there is no silver bullet for this on the so the best plan that I have ever seen from the best operations people that I worked with is to figure out what the baseline of your system when its functioning is an alert when your system is not that all that means figuring out how to how many requester successfully serving permanent and a learning when it deviates from that more than 50 per cent figuring out when it's normal to have that deviate and not learning on that and it's actually a ton of work because every single application has a completely different norms on some rails applications they serve like 50 requests and then it and that runs the entire profitable business some rails applications of hundreds of thousands of requests emitted and they're not profitable I like you need to figure out how it is that your metrics look when your company is functioning both like software wise and like company wise and you need to kind of alert when it's not the thing that gives you the indicator that things are that's that you should specifies that that so yeah any more questions the right and that it is not about the stuff later my the the
Kartesische Koordinaten
Schlüsselverwaltung
Neuronales Netz
Rechenschieber
Mereologie
Ausnahmebehandlung
Computeranimation
Dämpfung
Momentenproblem
Prozess <Informatik>
Open Source
Web-Applikation
Interaktives Fernsehen
Projektive Ebene
Softwareentwickler
Computeranimation
Proxy Server
Punkt
Versionsverwaltung
Gruppenkeim
Kartesische Koordinaten
Computeranimation
Lastteilung
Internetworking
Datenmanagement
Notebook-Computer
Kontrollstruktur
Router
Softwareentwickler
Gerade
Serviceorientierte Architektur
Assoziativgesetz
App <Programm>
Mailing-Liste
Bitrate
Dialekt
Energiedichte
Verbandstheorie
Mereologie
Server
Neuronales Netz
Subtraktion
Bit
Punkt
Prozess <Physik>
Zahlenbereich
Computeranimation
Lastteilung
Übergang
Weg <Topologie>
Knotenmenge
Fächer <Mathematik>
Reelle Zahl
Stichprobenumfang
Endogene Variable
Datentyp
Softwareentwickler
E-Mail
Gerade
Trennungsaxiom
App <Programm>
Graph
Zwei
Biprodukt
Teilbarkeit
Dienst <Informatik>
Rechter Winkel
Server
GRASS <Programm>
Resultante
Mathematisierung
Zahlenbereich
Kartesische Koordinaten
Framework <Informatik>
Computeranimation
Eins
Internetworking
Lastteilung
Virtuelle Maschine
Weg <Topologie>
Existenzsatz
Ganze Funktion
Einflussgröße
Bruchrechnung
App <Programm>
Güte der Anpassung
Soft Computing
Dienst <Informatik>
Rechter Winkel
Konditionszahl
Gamecontroller
Strategisches Spiel
Server
Verkehrsinformation
Zeichenkette
Neuronales Netz
Subtraktion
Formale Sprache
Kartesische Koordinaten
Framework <Informatik>
Code
Computeranimation
Überlagerung <Mathematik>
Leck
Virtuelle Maschine
Weg <Topologie>
Reelle Zahl
Vererbungshierarchie
Thread
Optimierung
Interpretierer
Graph
Profil <Aerodynamik>
Rechenzeit
Last
Rechter Winkel
Festspeicher
Grundsätze ordnungsmäßiger Datenverarbeitung
Mereologie
Server
Overhead <Kommunikationstechnik>
Speicherbereinigung
Verkehrsinformation
Aggregatzustand
Subtraktion
Punkt
Virtualisierung
Extrempunkt
Gruppenkeim
Zahlenbereich
Zellularer Automat
Kartesische Koordinaten
Zentraleinheit
Code
Computeranimation
Gradient
Gebundener Zustand
Hydrostatik
Virtuelle Maschine
Weg <Topologie>
Client
Prozess <Informatik>
Software
Speicher <Informatik>
Einflussgröße
Hilfesystem
Benchmark
Umwandlungsenthalpie
Suite <Programmpaket>
App <Programm>
Interpretierer
Dicke
Hardware
Linienelement
Matching <Graphentheorie>
Quellcode
Biprodukt
Quick-Sort
Generator <Informatik>
Dienst <Informatik>
Soft Computing
Benutzerschnittstellenverwaltungssystem
Rechter Winkel
Festspeicher
Server
Größenordnung
Instantiierung
Neuronales Netz
Bit
Linienelement
Datentransfer
Kartesische Koordinaten
Computeranimation
App <Programm>
Linienelement
Extrapolation
Zahlenbereich
Ungerichteter Graph
Computeranimation
Normalverteilung
Flächeninhalt
Rechter Winkel
Mittelwert
Mustersprache
Server
Information
Metropolitan area network
Lineares Funktional
App <Programm>
Punkt
Normalverteilung
Graph
Mittelwert
Rechter Winkel
Ein-Ausgabe
Kurvenanpassung
Computeranimation
Resultante
Videospiel
Punkt
Linienelement
Graph
Zahlenbereich
Einfache Genauigkeit
Fortsetzung <Mathematik>
Zeitzone
Computeranimation
Reelle Zahl
Mittelwert
Rechter Winkel
Minimum
Kurvenanpassung
Steuerwerk
Gerade
Benchmark
Lineares Funktional
Twitter <Softwareplattform>
Linienelement
Mittelwert
Computeranimation
Punkt
Mathematisierung
Gruppenoperation
Versionsverwaltung
Zahlenbereich
Ungerichteter Graph
Computeranimation
Lastteilung
Spannweite <Stochastik>
Mittelwert
Indexberechnung
Gerade
Umwandlungsenthalpie
Graph
Krümmung
Einfache Genauigkeit
Medianwert
Druckverlauf
Rechter Winkel
Gamecontroller
Server
Information
Speicherbereinigung
Neuronales Netz
Aggregatzustand
Virtuelle Maschine
Graph
Rechter Winkel
Zahlenbereich
Kontrollstruktur
Gerade
Computeranimation
Subtraktion
Menge
Mittelwert
Lineare Regression
Zahlenbereich
Information
Gerade
Varianz
Korrelationsfunktion
Computeranimation
Mittelwert
Server
Kontrollstruktur
Wort <Informatik>
Ungerichteter Graph
Computeranimation
Nichtlinearer Operator
Lineares Funktional
Linienelement
Automatische Handlungsplanung
Kartesische Koordinaten
Physikalisches System
Code
Computeranimation
Software
Mittelwert
Informationsüberlastung
Mereologie
Indexberechnung
Normalvektor
Softwareentwickler
Standardabweichung
Neuronales Netz

Metadaten

Formale Metadaten

Titel Don't Forget the Network: Your App is Slower Than You Think
Serientitel RailsConf 2016
Teil 24
Anzahl der Teile 89
Autor Arko, André
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/31508
Herausgeber Confreaks, LLC
Erscheinungsjahr 2016
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract When you look at your response times, satisfied that they are "fast enough", you're forgetting an important thing: your users are on the other side of a network connection, and their browser has to process and render the data that you sent so quickly. This talk examines some often overlooked parts of web applications that can destroy your user experience even when your response times seem fantastic. We'll talk about networks, routing, client and server-side VMs, and how to measure and mitigate their issues.

Ähnliche Filme

Loading...