Presentación
PDF (pincha para descargar)
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
and all right so a couple of quick things before we start the presentation I think we have a fairly short time window so I'm going to ask you to try to hold up the questions until the end and if we won't have time for questions then I'll be around
both later on today and tomorrow so come find me if you have any questions around any of the slides or anything that comes up so a few quick words about myself so I've been working on PHP for quite some time worked on variety of extensions a little bit
unzen engine variety of other pieces so kind of you know worked with PHP both is a user and as a developer of the language and my day job I work at a small company in Canada code center where we actually use PHP and a lot of similar technologies to develop
enterprise applications for home services industry so that's kind of where my day-to-day experience with PHP comes and from so what I wanted to talk about today is bottlenecks and I wanted to take a slightly different approach then just you know saying
how you're going to optimize your code because that's been done many times and you know I've done those stocks myself once or twice as well but one of the things that I find especially when looking at real applications is that often looking at
the programming language being at PHP or whatever other scripting language you may be using that may not always be the source of the actual bottleneck and really have to look at the entire process of what is going on in terms of the request handling and where
the potential issue is and that ultimately is going to tell you wearing to expand your efforts in order to try to make things better so the way I look at it you really have to from a bottle next perspective examine the entire task and this has begins of the
browser and one of the common mistakes that a lot of developers make is they look at the code that they write and say ok let's start from that point but really when it comes to performance or whatnot the process begins from the user and ultimately it's
the user could judges whether your application faster whether it's slow or whether it's something they want to use and the first thing that the user is going to interact with is their browser which is ultimately the tool that they're using to render
your particular website so that's one of the first things you need to take a look at and the browser has a whole series of bottlenecks that you need to contend with you have things like DNS you actually have to translate your web URL into the IP address
or multiple IP addresses if you're using things like CDN or similar entities you have to look at latency like where is your content located is it's taking too long to download because your server happens to be somewhere in Asia and a user happens to
be somewhere in North America there's you know speed of light is fast but it's not you know infinite so to speak you also have to look at basic things like page size what's what's the amount of JavaScript that you're loading CSS and all
the other components and the browser is going to need to process in order to generate the content for the user now once the browser did it think you also have to look at the web server and the web server does a lot of things that people forget about as a cell
negotiation being one of the big things which is a fairly complex process and nowadays because of security concerns or whatnot more and more websites are switching entirely to SSL so that is something you certainly need to take a look at things like caching
compression typically are considered to be a good things for performance but in some cases they can actually be a source of a bottleneck and that's something that we'll talk about in detail as well and also request pre-processing one of the examples
that I you know like to recall in this case is couple of years back somebody asked me a question of you know can I take a look at their application and figure out why it's slow because they couldn't figure it out and you know they used the standard
profiling tools and the requests were being generated really really quickly but after spending a little bit of time of looking at what's going on the problem was actually not the application it was actually the web server because what they had they had
a ton of mod rewrite rules which if used mod rewrite you probably know it's not the fastest thing in the world and had something like 10 kilobytes of mod rewrite rules do all kinds of strange euro transformations and that was actually taking five times
longer took the PHP script that they had in the back end to generate the content so that's just kind of one of the examples of things that you need to contend about now when it comes to scripting languages and I guess this is a PHP conference so we'll
use PHP is the name you have the typical issues like the slow code lock contention errors which I have an interesting example down line so you know the typical issues that you would find whenever you're writing your code the other bit which you could be
relating to caching layer or your database is the slow queries which you know is a common thing that people look after lock contention cache misses index lacking all those things can be potential sources of bottlenecks so at the end of the line anywhere throughout
the web serving stack you can have possible problems so lots and lots of reasons now one of the as i mentioned common mistakes is that people do is they use a common tool called the patchy bench how many people here use the patchy bench okay so quite a few
hands they run a command similar to this they say okay send a thousand requests to a euro of my choice and then take a look at the bottom portion which basically says okay I had no failures um there was no errors so to speak I can do about two thousand requests
per second which means excellent you know my application is running really really quickly unfortunately that still means that the user looking at this application may say okay you're able to send me the data really really quickly but by the time my web
browser renders the data a whole of a lot time passes because as great as apache bench is the only thing that it's testing is how long does it take for PHP to output the content of the page it doesn't consider things like external resources like CSS
javascript images whatever other content you may be loading as part of that request as well as how much processing time the web browser is going to need to actually convert whatever it is that you're sending into content that the user is able to see so
really the first step of bottleneck analysis are profiling is really to take a look at the user experience and there are some really good tools that will help you identify some common problems that may be related to that browser component now one of my favorite
tools for that is actually the chrome web developer tools and this is one of the profilers that is generates and the website that I've decided to analyze is actually a php.net so you know let's poke a little bit of fun at ourselves if you will so what
PHP nappin has the first blue line there at the top is the actual content of that particular page and what you can see from this content of the page that it took roughly a fifth of a second just to establish the connection which means that before any processing
was done a quarter of a second had gone by which means this whatever the server was doing was quite intensive the other issue was that you know PageSpeed so after the connection was established how long did it actually take for the web server to transmit the
data back which in this case was another you know fifth of a second so maybe php.net front page is particularly complex because it shows you all kind of thought stuff like upcoming conferences etc etc etc so that may not necessarily be a problem but the other
interesting bit is it took 1.2 seconds for the user to actually receive the page and now this is a cheated a little bit I did the slide at another conference and if you know the Wi-Fi speed at a conference is not particularly great so it took a while to download
the page but from an example perspective it's possible that you're generating the page really quickly but the size of the page makes it really long for the browser to download so as much as we all like to believe that our users have a very fast connection
that's not always true and that's why it's important to look at how you can minimize the size of the page and what other things you can do to reduce the load involved in a data transmission now the other interesting bit is that there is those I
guess purple lines which talk about how long it took Stu serve static pages so in this case it was one of the images that is part of the website and what's interesting here is that even for a static image it took 167 milliseconds for the web server to
transmission of that data so what it means is that when it was sending a dynamic page which took about two hundred milliseconds really only about 20 milliseconds was probably PHP or whatever was used to send the request the other 160 milliseconds was something
that the Webster was doing so that's probably a good sign that you having a bottleneck on a web server side maybe you have too many rewrite rules maybe you're having a lot of filtering happening maybe you have not security installed and it's spending
a lot of time filtering whatever input is coming through and that is a potential issue you want to take a look at because just from a benchmark of the application you may not be able to spot that but when you're doing it as a user this is a clear issue
that you ideally we want to address so the other thing you want to the other victim if you will don't want to take a look at is a pretty popular website called Facebook I'm sure most of you have access that at one point or another so Facebook has a
rather interesting situation so to serve the actual PHP content page they do it in about 400 milliseconds which is not particularly great but not particularly bad but what is interesting is that it takes another 400 milliseconds for that page to finish effectively
[ ... ]
Nota: se han omitido las otras 5.187 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.