Type UWSGI; Press Enter; What Happens?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 8 | |
| Number of Parts | 48 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/33173 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DjangoCon US 20178 / 48
2
5
6
14
16
23
26
30
31
32
34
39
43
48
00:00
Data typeProcess (computing)Computing platformComponent-based software engineeringComputer networkProcess (computing)MereologyPlug-in (computing)Right angleServer (computing)Object (grammar)Reading (process)Product (business)Operating systemLevel (video gaming)Proxy serverCommunications protocolSoftwareSoftware developerWritingData managementMobile appProjective planeComputer animation
01:47
InfinityInformation securityGenderType theoryData miningCuboidOperating systemLevel (video gaming)Operator (mathematics)Radical (chemistry)Computer animation
02:19
Service (economics)Process (computing)Computer-assisted translationMechanism designoutputComputer fileVideo gameService (economics)Basis <Mathematik>Mobile appPoint (geometry)InternetworkingStapeldateiLink (knot theory)Computer animation
03:22
Service (economics)Web pageProcess (computing)EmailMobile appServer (computing)Type theoryDemonStapeldateiPresentation of a groupLine (geometry)Computer configurationPhysical systemFunction (mathematics)Point (geometry)Slide ruleProcess (computing)Principal ideal domainContext awarenessDiagramBitGreatest elementIntrusion detection system
04:42
Computer-assisted translationInternetworkingBeta functionMultiplication sign2 (number)DiagramRight angleBitTrailProcess (computing)Machine learningWeb pagePixelMobile appWeb applicationComputer animation
05:44
2 (number)Normal (geometry)Structural loadBeta functionComputer-assisted translationHome pageWeb pageMobile appComputer animation
06:15
Process (computing)GenderProcess (computing)Multiplication signCoprocessorDifferent (Kate Ryan album)Intrusion detection systemMultiplicationComputer animation
06:47
Service (economics)Local ringEmailComputer networkLie groupHome pageDiagramEndliche ModelltheorieServer (computing)Computer fileoutputProcess (computing)InternetworkingWindowStructural loadWeb pageBitCore dumpWeb applicationLibrary (computing)RoutingCartesian coordinate systemSheaf (mathematics)InformationFunction (mathematics)Mobile appCase moddingMultiplicationComputer animationDiagram
08:36
Network socketCodeInformation securityInformation securityConnected spaceProcess (computing)Graphical user interfaceError messageKernel (computing)Socket-SchnittstelleRight angleCodeNetwork socketComputer hardwareRevision controlLine (geometry)Web browserSystem callBitFunctional (mathematics)Server (computing)Complex (psychology)Cartesian coordinate systemSpacetimeService (economics)NeuroinformatikCore dumpCombinational logicAsynchronous Transfer ModeRing (mathematics)Computer fileKeyboard shortcutMultiplication signDiagramCuboidEntire functionQueue (abstract data type)Point (geometry)View (database)NumberOperating systemFerry CorstenUncertainty principlePower (physics)Symbol tableParameter (computer programming)Physical systemSoftware frameworkMereologyBasis <Mathematik>Mechanism designAreaPatch (Unix)QuicksortOrder (biology)Software testingVirtual machineInheritance (object-oriented programming)Special functionsVulnerability (computing)Object (grammar)WordWeightDegree (graph theory)SoftwareSet (mathematics)State of matterLevel (video gaming)PC CardDependent and independent variablesGenderComputer animationProgram flowchart
17:17
Information securityComputer fileProcess (computing)Fluid staticsSystem programmingRead-only memorySynchronizationCodeComputer networkFluid staticsComputer fileSemiconductor memoryRadical (chemistry)InternetworkingAddress spaceSingle-precision floating-point formatConfiguration spacePhysical systemServer (computing)Information securityDifferent (Kate Ryan album)EmailTraffic reportingMultiplication1 (number)Electronic mailing listType theoryProcess (computing)Decision theoryWeb 2.0Network socketCartesian coordinate systemBasis <Mathematik>Plug-in (computing)CASE <Informatik>Point (geometry)File formatTerm (mathematics)Structural loadCodeProxy serverAuthorizationAsynchronous Transfer ModeASCIIOperator (mathematics)Perspective (visual)Computer configurationLatent heatNumberMereologyMultiplication signSoftware developerFormal languageRootLeak2 (number)CuboidException handlingTelecommunicationKernel (computing)Right angleProduct (business)Datei-ServerMaxima and minimaWeb pageWordEvent horizonBitArithmetic meanMoment <Mathematik>Wage labourEndliche ModelltheorieCovering spaceMatching (graph theory)Physical lawLine (geometry)Water vaporGradientComputer animation
25:59
Computer clusterXML
Transcript: English(auto-generated)
00:16
Whiskey press enter what happens if this is the talk you're here for congratulations if not you're totally free to leave and in fact to give you
00:23
that opportunity I'm gonna ask you all to do three things for me real quick first thing I ask everybody to do it's late in the day everybody stand up real quick we're just gonna get we're gonna get ready for the talk please place your hand over your heart take a step to the left
00:41
fantastic now you can say that if no matter else what happens the talk was uplifting heartwarming and moving so let's say you've built a Django app you're ready to share it with the world you tell your friends about it and they think hey this thing is really great but when you deploy it when you put it out for the world you shouldn't be using Django run server you should be
01:01
using you whiskey you whiskey you say what's you whiskey and you're a clever developer so you go and look at the you whiskey project documentation and it says things about being a proxy it says things about taking care of protocols and managing processes that you can apparently write plugins and CC plus plus and objective C and this seems very informative but it
01:21
doesn't answer the fundamental questions you have about what is you whiskey what's it doing and why should you use it and those are the questions we're going to try to answer today how does you whiskey handle processes from the operating system level how does you whiskey handle networking from the operating system level and then why should you
01:40
use you whiskey and to tell you that I'm gonna tell you about like why I use you whiskey my name is Philip James if you were at Django Con last year you might remember my talk frog and toad learn about Django security if you've been to other pikons you may have seen another talk of mine type Python press enter what happens and in that talk I went through the what it was on
02:04
the box what happens from the operating system level when you type Python and press enter you may be aware that if you type Python and press enter you get the prompt at the terminal but what is the operating system doing under the hood to make that happen and so in that talk we talked about how there
02:21
are these things called processes and a process that you might use to start Python is a process called bash bash starts the Python process by making a copy of itself and then changing that copy to the Python process through a technique known as forking and exacting and that process gets access to these
02:41
things called file descriptors which are the mechanisms that are used by the Python process for input and output for you to communicate with Python and for Python to communicate with you and that's the basis for our starting point here of how does you whiskey handle processes and to talk about that we're gonna talk about an app that I created a while back I couldn't find it
03:03
anywhere else in the internet I was really surprised but catserv cats as a service if you are in need of a cats as a service in your life there's a github link that you can go check out but the app is pretty simple you go to catserv and you get a cat now I did some digging because some people told me
03:26
to use you whiskey when deploying this and so I found a you whiskey incantation that would let me run this app from my server type you is key press enter what happens and what happens if you do this incantation for you whiskey
03:43
and actually a quick show of hands how many people have used you whiskey before ever in any context okay of those people who have their hands raised how many people knew that knew that you could run you whiskey from the command line just like blank command line options okay not as many and that was a realization for many of us as well is that you whiskey like many
04:03
things on Unix systems is a command you can run it the way that you would run it outside of a demon and so if you type you whiskey and press enter with these incantate with this particular options you get this a bunch of output we've condensed some of it and the line that I really want to point out here is that line at the bottom spawned you whiskey worker one
04:22
and it has this thing called a PID now you might remember from our previous slide that bash and Python had PIDs those are the process IDs and this line is you is he telling you hey I have spawned one worker one thing that is going to run your app and there's the process ID where you can
04:41
find it and so what that looks like if we were to diagram it a bit is there is this you whiskey process that you have started you whiskey forks itself and execs your Python app to make this running Python process running your app and when a request comes in now that worker is busy and
05:03
it's serving your request and that's great but we wanted to add an extra special feature to this web app you know we've been hearing a lot about machine learning we really want to be able to serve you the best cat not just any cat but the best cat specific specifically tailored for you so
05:21
I put a bunch of tracking pixels all across the internet to collect data on what was going to be the best cat for you and we put this behind this beta feature and we we tried really hard but we couldn't get the time to load the beta best cat for you under 10 seconds we think we could maybe do better in the future but right now the page takes 10 seconds and that's a bit
05:43
of a problem because as we see here if I'm loading the beta which you can see and then I try to load the normal home page well the home page used to load really fast and now it's not and in fact if we wait the full 10 seconds we'll see that it's only after the beta page loads with this
06:02
highly tailored cat for you that the normal home page cat loads and that's really not what we want you know it we don't want the beta feature to be basically making the rest of our app worse and so what we need to do is have uWSGI start more than one process for Django apps especially you
06:25
every time if you want to be able to serve multiple requests at the same time you need to be having Django run with multiple processes and so here we've added this dash p2 to the end of the command that we're using to run uWSGI and uWSGI tells us that spawned not just one but two uWSGI workers
06:44
with two different process IDs and so if we go back to our beta we'll see that we can have the beta loading in one window and the home page now loads independently hooray we've fixed our app again going back to the diagram the way this works is when uWSGI forks and execs it forks and execs two
07:04
processes and so while one is busy serving the beta page the other one can be serving our home page and our users still get a pretty good experience so that is basically the core of how uWSGI and realistically any other
07:23
Python web app server like G unicorn or some of the mod libraries for nginx or Apache are going to handle this they're gonna fork multiple processes and route requests to each of those different processes but let's
07:40
talk about what I mean when I say routing requests to those different processes so if we go back to that command I'm passing in HTTP 8000 and that's telling uWSGI I want you to run this application on that port and so if we look a bit closer we're gonna see look at the middle section of output now where we see some kind of relevant information that uWSGI is
08:10
a master process 1220 there's some other FDs there and if you remember from talking about process at the beginning we talked about file descriptors being how input and output is connected to Unix processes
08:23
and uWSGI is giving us this hint here that these FDs are the file descriptors to these processes that are being passed around and bound to let uWSGI talk to the internet so let's talk a little bit more about that let's say you want to connect to a remote server and the remote server here is going to be a box and the way you connect to remote servers
08:42
through ports the ports here are represented as telephone jacks because a way that you can think about ports on your operating system is that they are like telephone lines that are waiting for things to connect to them and so you want to SSH into this box you're probably going to use port 22 if you've SSH into a box ever before you've probably used port 22 if you
09:02
used git you've probably used port 22 because you probably use it in SSH mode and so the first thing that SSH is going to do is it's going to connect this phone line which is our metaphor for a socket it's going to connect a socket to port 22 and then it's going to use that socket to
09:21
communicate through the port to the outside world now uWSGI is doing a similar thing on port 8,000 where it's connecting this phone line this socket to port 8,000 and then using that to communicate and accept connections coming in from outside there's a little bit more complexity but the socket and
09:44
port functions are happening in a space called the kernel the kernel is the core of the operating system it's where all of the interfacing with hardware happens and it turns out if you want to do networking you have to interface with hardware at some point and the processes like SSH D which is running SSH and uWSGI which are running your server are happening in
10:01
user land and there's a mechanism for user land processes to talk to the kernel and that's through syscalls syscalls are these special functions written in C and normally accessed in C that can tie right into the kernel let's go a bit deeper let's say you're on your computer you're in Chrome and you want to connect to your uWSGI server on port 8,000 well
10:24
you know that port 8,000 is going to be accessed by the kernel and the first and if uWSGI wants to bind itself wants to connect to port 8,000 so it can receive connections first of all the first thing you would notice is if you were to make this connection from Chrome to port 8,000 before any of the
10:42
connections have been done you would get a connection refused error right because there's no port exposed the kernel doesn't know what to do with this so it just tosses it back at you and so uWSGI needs to issue some syscalls to kind of get things set up so that it can accept requests from your browser the first thing it's going to do is issue the socket syscall to create that telephone line to create that socket and it's going to be
11:05
passed that socket as a file descriptor because if you're familiar with the Unix philosophy where everything needs to be some sort of file or at least file like object uWSGI needs this file descriptor handle to the socket that it's just created uWSGI then calls bind and what bind is going to do is
11:25
going to tell the kernel hey I've created this socket please connect this socket to the port that I specify so it's connected to port 8,000 and then uWSGI is going to call listen what listen is going to do is it's going to tell the kernel okay everything's set up ready to go please expose this port
11:42
8,000 to the outside world so that I can start accepting connections now it's at this point that uWSGI is going to do its fork and execing to create the worker processes and what's interesting about forking execing is when you fork and exec a process you get the same file descriptor
12:01
references that the parent process had so both the uWSGI master process and both worker processes have the file descriptor access to the socket that was created for port 8,000 and these two worker processes are going to call another specialist call called e-poll-wait which is effectively these worker processes telling the kernel hey we're both waiting for a
12:22
telephone call we're waiting by the phone as soon as somebody calls the phone we're ready to pick it up so now you can make your request from Chrome against port 8,000 the phone rings and both processes try to pick it up at the
12:43
same time they both have access to the file descriptor and they're both going to reach for the phone but they can't both answer the phone that one of them is going to win first they're both going to try to call accept to both try to pick up that phone at the same time but only one's going to win and the one that wins is going to get a new socket which represents the
13:02
connection from port 8 that from Chrome through port 8,000 to the Python worker process and it's now going to be handling the request while the other Python process issues the e-poll-wait syscall again letting the kernel know hey so the other guy won the first time but if a new request
13:21
comes in I'm totally ready for it and that was a very long complicated diagram but that's basically the core of it through a combination of syscalls and sockets uWSGI sets up a connection and then passes that a reference to that connection to its worker processes its child worker processes and those
13:41
child worker processes accept the connection to handle the request so now we get into now that we've talked about how uWSGI handles processes and we've covered a bit about how uWSGI handles networking for handling requests why would you use uWSGI and the first couple things that I'm going to talk about are not really specific to uWSGI they're kind of
14:02
applicable to any Python application server but a couple are going to be specific to uWSGI and I'll call those out so the first thing is code reloading this is something that the Django run server really can't do if you are trying to deploy a new version of your code you've got code
14:22
running on a service and you want to deploy a new version you want to be able to deploy that version without shutting down your entire server and bringing it or shutting down the application server and bringing it all the way back up so when uWSGI detects that there is new code to be run when you tell it hey I would like to change out the code on the workers it sends a signal to its worker processes the hang up signal SIG
14:44
HUP telling the workers hey as soon as you're done please exit and reload yourself and so in this example we've got one worker that's busy both workers get the SIG HUP so you know one isn't busy and so the one that isn't busy shuts down immediately the one that is busy kind of gets a little
15:01
notification indicated by the power symbol hey when you're done processing your current request you should shut down because you need to be reloaded it completes its request it notices that oh I should refresh myself it also shuts down now notice throughout this entire process uWSGI held on to that socket that was connected to the outside world so uWSGI didn't
15:23
never dropped a connection more connections might have been added to the queue during that time but uWSGI was always maintaining its presence to the outside world so from the user's point of view it may have been a little slower but they never got the connection refused so that's reason number one you might use uWSGI but that's pretty common reason number two
15:43
tunability earlier we noticed that when we were running our beta feature we needed more than one process in order to serve our application well and not have any users be blocked on our beta feature but why two processes why not 20 why not 200 and the answer is uWSGI will let you spawn as many
16:03
worker processes as you reasonably want but there's going to be a right number of worker processes for your system in my testing a Python application worker takes about 200 megabytes of RAM if your machine has about two gigabytes of RAM because you're running a small server maybe the
16:20
right number for you is 10 or 8 if you want to give some wiggle room but the important note here is that uWSGI lets you tune basically every parameter you can think of to match what your system needs again this one we think uWSGI makes it easier but it's also something you can do with GUnicorn and a bunch of the others security there's a very so overall the
16:45
Django team does an incredible job with security in any part of the framework that you would use on a regular basis that actually kind of run composes the application they are very quick to respond to security holes they release patches quickly but there is one area of the Django codebase where
17:03
they have said quite explicitly they will not do any sort of security audit or do any sort of security patches and that is run server directly from the run server is not going through security audits and that's how it's gonna stay and that might not seem like a huge deal but just as a small example this
17:25
is a the headers from an HTTP request right if you're familiar with this this problem makes a lot of sense if you're not familiar with this brief overview you are getting the root page over HTTP 1.1 on host catserv.io which unfortunately we don't own but you're welcome to create it and then
17:42
put our code up on it and that would be great and this seems pretty straightforward but what if you get a request like this what if there is a layer of your system that interprets the first header but not the second header or vice versa now it could be that everything here is fine but the
18:01
point to make is that the Django team has not thought about this case for run server and the uWSGI team has and so security is one of those things that whenever somebody says it everyone in the room including those people who work in security feel slightly inadequate it's more that you should be focusing your effort on using tools that have been vetted by people who
18:24
care about the security of their layer and the Django team has enough to worry about and so run servers not gone through security audits and that's how it's going to stay use a different application server again pretty common not necessarily specific to uWSGI another thing that uWSGI or
18:43
other application servers have in its favor is config files I showed this because the title of the talk is type uWSGI press under what happens but many of you who use uWSGI on a regular basis are probably more used to seeing a format like this that you have in a uWSGI conf file that you can check into git you can pass around as text files you don't have to remember
19:02
the magical incantation on your server you can just point you can just run uWSGI pointing it at this conf file and it will do exactly what you want to do captured and that's great because you get all the advantages of just having a text configuration file that you can again check in the git you can do code review on you can iterate on over time and you never have to worry about remembering the correct options that is a super
19:23
powerful thing that I think anybody here who's done since admitting appreciates again not necessarily specific to uWSGI so now let's talk about some things that are super specific to uWSGI uWSGI comes with so many features and so many modes of operation that you can probably replace
19:43
large parts of your existing infrastructure with uWSGI and you may not even know it for example uWSGI comes with a static file server if you want your workers to die after a certain number of requests because you think you have a memory leak and you can't be bothered to fix the memory leak right now you can set a max requests per worker on the worker
20:03
and it'll just restart after a certain number of requests uWSGI comes with a queuing system uWSGI comes with HTTP support HTTPS support and HTTP2 support right out of the box it comes with the HariKiri mode so if a single worker grows to having too much memory it'll just kill itself and start a new worker again if you've got a memory leak why debug
20:22
it today when you can debug it six months from now and just have uWSGI take care of it for you if you want to prove how well uWSGI is doing you can use uWSGI top if you want to see exactly where that memory leak is coming from eventually you can use memory report uWSGI supports async and so when I look at this list a thing I think to myself is
20:41
with all these things that uWSGI can do do I still need a separate queuing or static file serving system do I still need celery do I need redis what else can you do so why uWSGI code reloading and tunability are pretty common security config files and just so many features
21:05
if you haven't dived in dove into the uWSGI docs yet highly recommended you will discover things that you did not know uWSGI could do and so that's about it special thanks to Unbit the guy who created uWSGI who reviewed this talk for me and my co-creator the person who helped me write it he
21:23
was incredibly helpful at answering questions if you have any questions I will answer them now we've got about five minutes my name is Philip James I am definitely so I do a whole bunch of things I worked in Django and Python for about ten years I am definitely available for consulting especially on security or performance so if your company is having problems that you
21:43
think could be solved by someone who's given talks on security or performance at Django cons definitely come talk to me that's my email address that is my twitter handle feel free to tweet at me it is my birthday you're also welcome to buy me a drink at the bar later tonight and with that I will turn it over to I think we have a couple minutes for questions thanks for the
22:01
talk every single tutorial I've seen on like how to get Django up and running on the internet says you make you use uWSGI and put it behind nginx why is that especially if uWSGI can do static file serving that was I thought the whole point of using nginx that's a great question the reality is
22:23
that well you would have to ask the specific tutorial author why they made that decision ma our my guess on that decision is nginx is a technology that more people use as their kind of frontline server and so more people
22:40
trust it in terms of being that like termination point and being the kind of the heavy hitter in terms of taking the most load that being said I actually do think for most small to medium applications you could totally 100% get away with just running uWSGI but there are some things especially around
23:01
like certain special proxy configurations that nginx is going to handle better and that was kind of our my point with the like list of features is if you hit a point if if you think all of your use cases can be covered by uWSGI use uWSGI I think that uWSGI can't do quite as well is if you need to be actually that's not true it's got plugins I was gonna say there's
23:25
some languages that uWSGI doesn't handle quite as well but as plugins for most languages people that trust nginx more I think is a big part of that but for small to medium applications I personally wouldn't have any fear about using uWSGI just out in the wild and I think a lot of I think people do they just don't talk about it as much okay hi is micro
23:44
whiskey the same as uWSGI but ASCII micro has two syllables u has one syllable in a talk you're really stressed for time and so I chose to cut about a hundred syllables ish out of my talk by calling it uWSGI instead of
24:03
micro whiskey but thanks for the question so you've talked about a lot of awesome things about uWSGI what is the worst thing about it the worst thing about uWSGI is there's so much there that trying to actually parse what the
24:20
docs are telling you uWSGI can do is really tricky the docs are definitely written from the perspective of someone who is a web engineering professional and could be far more beginner friendly especially for exposing some of these cooler advanced features happy birthday Philip my Chris yeah my question is so in terms of the process that happens with
24:43
the communication with the kernel where the socket is open and the port is exposed how is it different from the run server what does run serve it do under the hood except for the fact that it doesn't can't have multiple workers so when I was creating this talk I was definitely under the impression that run server didn't have multiple workers and then it turned
25:01
out that run server sometime in when no one's looking added multiple workers so run server actually does do a lot of the same dance that uWSGI does but there are things like in that list of features that I described that run server can't or won't do and realistically like run server is a
25:24
hundred percent fine for development but I trust the team when they actively say please please please do not use this in production because they there that's never going to be a priority for them and I think that I've seen them like actively red not maybe not like meanly but like actively reject packages for making it more production ready because that's not the goal of run
25:42
server but it's doing most of the same dance of like spawn some processes and then have them wait on a socket because it does do multiple processes now all right thank you very much
Recommendations
Series of 38 media