record QD implementation of the boundaries and garden model please now okay better, okay Yes, thanks. Yeah, whereas we got so much used to the masks They are almost fixed on the place So thank you very much the organizers first of all for the Organization and invitation to this very nice meeting in the place that I like very much It's always a pleasure to come back Then of course I have to thank my collaborators. So it's a joint theory experiment work. So the experimental part Okay Yeah, okay, so the the main Experimental work was done by Sebastian Lerge who is who was a PhD student at the Neal Institute and so Two of his supervisors are here in the audience The theory part was done by Tosypoulk who was also a PhD student at Neal Institute with the search Florence and There was also Contribution from Isaac Simon and myself So Isaac is in Johannesburg and I'm in neighboring laboratory to the Neal Institute so I Was looking for a nice picture in Grenoble But I did not so I had little time and I just took the one that I had from my office window a few months ago So that's kind of Typical we are randomly chosen if you want not not specially tuned and not specially selected Okay, so the outline Well, I will give first some motivation which may be a little bit personal and Kind of subjective then I will describe the experiment system the experimental part Hopefully I will be able to do it correctly in if not there is Nikola and Olivier and Then I will discuss two theory aspects And there is of course a lot of overlap with the previous talk. So I will try to make connections Okay So motivation You have already seen boundary sign Gordon model. So we have this is the Lagrangian. This is basically an elastic string semi-infinite in this case and on the boundary we have this cosine Cosine term so this is called boundary sign Gordon if you put this cosine Inside the integral then this is called bulk sign Gordon. I will be speaking mostly about boundary So this model is well known. It's integrable and it has been solved exactly So the question is why should we bother studying it if everything is known about it? Well to my taste This model so this come this Lagrangian if you take it literally It's just a meaningless combination of letters because this Symbol J You don't know what it is unless the model is supplied by a short distance cutoff and Then many things depend actually In on the details of how how this short distance cutoff is implemented So it's better to say that this is not a model But it's rather a class of equivalence of models. So you have so you need always to start from Some latest model which is well defined at short distances And then when you go to low energies and large distances then you have Universal physics that comes out and this universal physics is somehow can be somehow extracted from this Boundary sign Gordon Lagrangian But the problem is that You so first of all there are phenomena that are not that Depend essentially on on this cutoff on this short distance physics and even if you study phenomena, which are supposed to become universal at this low energy scales How to control the so you have kind of asymptotic so this exact solution or this Integrability property that we heard about they predict The asymptotic infrared behavior of the model But how to control how well you are in this infrared limit and this you cannot Really do from the model from the model itself to control the theory you always have to come back to the latest model and So to give some examples So one example that we Recently did so we were studying the phase diagram of Offered Josephson junction chain Which so this is just the very standard Let me show you the so the very standard model for the Josephson junction chain without so all junctions identical Josephson energy Capacitance matrix so with the islands are coupled by the capacitance matrix you have the two capacitances in the problem so for this model you can want to study phase diagram and From if you think so this is supposed to be in the class of equivalents of bulk sign Gordon and So you have you know that there are two phases Superconducting phase insulating phase you know that the transition is Costal it's belongs to costal established University class you have scaling that is known since many years but if you try to establish to guess the phase diagram looking at this universal scaling trying to see which Which of the parameters of the latest model are renormalized in which way Then you would not guess the correct the correct form. So what we found is that this boundary is determined by some much more Stupid and dumb short-range effects then the which which dominate over the costal established scaling Even more Spectacular example is this recent story about Schmidt transition So what you guess from this universal scaling laws is this kind of phase diagram? so you have dimensionless resistance and the ratio e j to e c so from the scaling you would guess that your Boundary between the two phases would be vertical And so the experiment was done Which was supposed to be in according to this phase diagram in the insulating state They did not find the insulating state So they started to suspect that there is no phase transition at all but in fact if you Take this model and you simulate Taking into account all short distance effects then oops, sorry The phase diagram actually looks quite different. So this is a game Beyond the this usual sympathetic scaling that you would get from From the effective field theory and you see that the insulator phase is actually much more much more narrow than What you would think. Okay, so this is my motivation so the when you want to study something that some latest model that Boils down to a quantum field theory in the infrared limit then To control this infrared limit is not so easy. You cannot really control it based only on the quantum field theory Okay So now I go to the main topic So this is the experimental system and it's very very similar to What we saw from the previous talk. So there is a Josephson junction chain and In this part. So there is like 400 junctions which are large enough. So the cosine The Josephson cosine you can expand into Up to quadratic order and then you get just a harmonic chain Which you can think of transmission line which hosts linear modes So here there is our boundary impurity which is a squid So that you can control the Josephson so this remains a cosine and the coefficient in front of this cosine you can control by External magnetic field Then you do on the left side you have The external circuit where you send microwaves and you can measure their transmission So this the Hamiltonian of this is so if we just think about the chain and the boundary Just just this part. It's the harmonic part for the chain So there this small junction also has some capacitance and this capacitance goes into the harmonic part of the Hamiltonian And we have the the boundary the the cosine at the boundary. Yeah, sorry for the pointer I'm still high. I have to adjust to the speed of it. Maybe I don't know if I stand here. Maybe it's better Yeah, slightly better, okay. Yeah So the typical result from a measurement is this so you measure so you send photons into your transmission line so you send Incoming photon here you collect them here. So the transmission coefficient typically as a fun as a functional frequency has a form with some sharp dips and each deep is corresponds to standing wave in the chain And when you tune your flux Through the squid through the small squid you change the positions of these dips and also the widths and You can think of this as Modified so flux modifies this Josephson energy Which is standing here and this modifies the the modes of the chain and this is how you measure this So first of all, how are these modes made so if we take an infinite chain this harmonic Hamiltonian that I wrote on the previous slide and Just look for the linear modes Which are plain waves then we have a certain dispersion Which is linear only here at low frequencies and Then it deviates and saturates. So there is a natural cutoff In this latest model, which is called plasma frequency, which is 18 gigahertz here so this and When you take the experimental This experimental dips and you put them on the On the you just Put them on your plot as a function of the wave number you have this This dots and you can fit the dispersion relation and you get all the parameters of your chain So if you want to see how the they are spaced How is the quantization? Condition for the standing wave then you have to look at the boundary conditions of the at the ends of your chain So on the left we have this transmission line a 50 ohm and this is almost grounded on the right we have this element small junction and In the very first approximation you can think okay. Let us take it also quadratic Expand this cosine then we have something some effective boundary condition, which is sensitive to the flux and this boundary condition introduces a phase shift scattering phase shift and then this determines the positions of the of the modes and By measuring how the positions depend on the flux you can extract this phase shift and See how it behaves on the frequency. So this is the Plot of the scattering phase shift as a functional frequency for different fluxes So what does it tell us? the most important qualitative feature of this Curse is that they are very smooth and this means one thing here at the end you can think about a Of this small junction So we already heard in in the previous talks yesterday that you can see it can be a qubit or you can think of it as a Harmonic oscillator or a weakly a harmonic oscillator transmon Something that has its own energy levels and then if you if it has well defined energy levels then the It would produce Resonances for the modes of the chain if you have well defined resonances then your scattering phase shift Various very sharply when your frequency goes through the resonance. So the smooth nature of this Curve Tells us that there is basically no resonance that the It's completely over damped by the strong coupling to the modes of the chain and this is Where it is where this system is different from the works that The previous speaker Discussed so in particular the experiment in Manuchiran's group group so and then this means that we this is this system is Indeed more similar to the boundary sign Gordon where you have just the cosine you don't have any Internal dynamics associated to your boundary all the dynamics is in the chain and you just have this non-linear cosine at the boundary Okay, so scattering shifts that we can so now I will move more to theoretical part. So the first thing to Understand and to model is this scattering phase shift Which depends on the frequency and depends on the flux. So if we just take As I said Replace and replace this non-linear element by something effectively Linear then of course the phase shifts you can calculate exactly, but this is not this will not Correspond to the experimental result the effect of the non-linearity in the very first approximation you can think of Effective renormalization of your cosine by vacuum fluctuations so basically this Tells you that your Ej becomes renormalized it's that we call Ej star Renormalized by the vacuum fluctuations, which is well this kind of factor You see it like Dubai Waller factor. This is all comes from the same Physics renormalization by your harmonic environment So you can Put this this procedure into a self-consistent Into a self-consistent scheme, then it's called self-consistent harmonic approximation So basically this Delta Phi square you evaluate this by taking your by putting your linear element as As As some some effective inductance that is not exactly the bear one this is so this is known since long ago this procedure and you can view this as self-consistent Dressing of your self-energy or you can view it as the best Variational wave function from the Gaussian family for which you can From which you minimize the energy of the system, so The result is Not bad, so you see that the effect is strong enough we have a factor of So this the dashed line is the bear The bear ej that you would just guess from the squid From the Aron of bomb pre-factor So well, this is the actual ej star that you extract from the Positions of the pigs transfer translated into phase shifts translated into ej star So this is the the dots are the experimental curves, so we have This Magenta line is the self-consistent harmonic approximation Which breaks down? at some point when ej becomes too small The Dotted line is the universal scaling that you get from the boundary sine Gordon So our alpha here it's 0.3. So we are on the superconducting side of oops, sorry Superconducting side of the Schmidt transition. So here you see the behavior of the experiment of the experimental points it goes quite well with the With this universal boundary sine Gordon scaling breaks down at some Low frequencies low energies because of the finite temperature and the scaling is of course zero temperature result and at high energies it deviates because we have cut off So the theory you you really start feeling latest effects and this self-consistent Harmonica approximation of course takes care of all the latest effects correctly more Interesting is the decay. So this is precisely the The topic of the previous talk So you see we have as a function of flux and frequency the quality factor of the of the modes changes And this is the photon Down down conversion, which okay, so I don't have to explain what it is because the previous speaker did a very good job at this So how to model this? So here We want to take into account these latest effects and to implement the ultraviolet cutoff as it is So what do we do? So first of all So here we Introduce the greens function Of the face or face face correlator the transmission coefficient Into this in this transmission line you can relate it exactly to the greens function so the greens function Satisfies the Dyson equation in this Dyson equation here everything is Harmonic so C and L minus one are the capacitance and inverse inductance matrices of this whole whole thing So This is the damping introduced by the transmission line on this side and all the effect of the non-linearity is Sitting here in this self-energy Which is located only on this last side So this if we have the self-energy then we have this equation for the greens function. So the whole Interesting physics is in the self-energy. So what do we do with the self-energy? So we do We do perturbative calculation in the Josephson We this is because our the most Interesting that the strongest effect you see is near half flux Near half flux quantum where the Josephson is suppressed five minutes. Yeah, thank you So So we do Perturbative we have a perturbative expression for the self-energy up to the Up to second order So this Takes into account you see it still Takes into account in elastic processes to so Multi-photon production not just one to three but also one to five one to seven but to Perturbatively in Josephson This is controlled at high frequencies if the frequency is higher than ej star. This is what the previous speaker also Mentioned so we are on this high frequency side It's it can be easier easily generalized to finite temperatures and this is what we actually do. So here I wrote The zero temperature version, but you can put Keldish and put in put the finite temperature So we do self consistently again. It's a self consistent born approximation Because this greens function is the one that should be determined from this equation This defines the self consistency loop So it captures a lot of Useful effects. So it When you do it on the self consistent level You take into account the fact that the photons into which your decay. They are not the Bare photons, but they themselves are dressed and they themselves decay So you have this hierarchy of multi photon cascades Level this is important because we have a finite chain and the level discreteness matters More the more discreteness matters in this chain. So With this you can also describe many body localization or delocalization. So in our case, it's delocalization Because the peaks that we observe are smooth Lorentz and peaks in the in the transmission What this approximation misses it misses the quantum phase slips because it's perturbative in Ej So you do not go to the next minimum of the cosine so So this is the result for the flux near flux quantum, which is so well in the So this is the the parameter which controls So when we are within this Applicability regime, it's fine our theory Feeds the experiment reasonably well You see that this decay the frequency dependence is Rather exponential because we have linear scale here and logarithmic here and it's not at all the power law that you would expect from the From the boundary sine Gordon infrared asymptotics But so this is a success if you try to go to fluxes, which are smaller than Significantly smaller than half flux quantum Then you are out of the regime of applicability and then this self-consistent born second order it miserably fails You see there is so Search and to they even tried to push it to the third order But once your second order breaks once the leading order breaks you usually need all orders So the third order pulls you in the good direction, but does not cure the situation And in this regime, I think we don't have any Reliable theory available which would account both for the latest effects and for the all non perturbative stuff and This is all I wanted to tell you. Thank you very much. Thank you Okay The talk is open to discussion Thank you very much. So just to make sure and this then so you're claiming that what leads to the different Dependence of the decay rate makes it exponential not a power law is the dressing of the photons or what is the reason that you you get this deviation? You mean this exponential instead of power law. Yeah, this is Bad separation of scales e. J. Star and ultraviolet cutoff. We are not still not in the scaling regime Infraredo synthetics and see so what you need to get in this regime is I guess longer chains or Low longer chains and lower frequencies and I see okay. I don't know which one is more constrained Constrained for experimentalists I Wouldn't I would propose we thank the speaker. Thank you very much


Wyoming is famous for many things, including its outlaws. Wyoming's outlaws have a rich history in the state, and the Sundance Kid is no exception. Harry Longinbaugh was born in 1867 near Philadelphia, Pennsylvania. He got his start in the West as a cowboy working at different ranching operations. During hard times in the Black Hills, Harry stole a horse, pistol, and supplies near Sundance, Wyoming. He was sentenced to 18 months in jail. While in jail at Sundance, he received the alias the Sundance Kid. Once released, the Sundance Kid continued to work as a cowboy and never far from trouble. He eventually met up with Butch Cassidy and joined a group of outlaws known as the Wild Bunch. The Wild Bunch was famous for committing train and bank robberies throughout the Western US. Feeling pressure from law enforcement after many years of crime, Cassidy and the Sundance Kid eventually relocated to Argentina. While living in South America, the two ran into trouble with Bolivian authorities. The men were trapped in a small house where a gunfight broke out and eventually took the lives of Cassidy and the Sundance Kid in 1901. There are many theories and debates surrounding what actually happened to the Sundance Kid. While we may never know the exact truth, it is easy to imagine early day outlaws riding across the open spaces of Wyoming. From the University of Wyoming Extension, I'm Brian Sebade exploring the nature of Wyoming.


Hello everybody, so I am Aditya, I work at PLEVO, in this talk we will be seeing what G-Vent has to offer to help us build highly scalable web services. So I work as an infrastructure engineer at PLEVO and part of my work is on optimizing and scaling our various internal services. So G-Vent is used in nearly every project at PLEVO and it has worked quite well for us to help us scale up and it's the async framework of choice for us. So let's go to the core problem of what happens when we try to run a web server in Python. The problem is simply blocking IO. So any typical web server, a request involves accessing multiple requests to internal services like a different API service that you use that is provided by some other company or accessing a database or a server or RIDIS and the problem is that while your web server process has made a request to one of these external servers, it's blocked, it can't respond to any more requests, it's simply waiting. So standard web server, Python for example like G-unicorn, they run multiple processes where each process will respond for a request and the problem with a server like G-unicorn is that while it's processing one request, if it's not using some async framework, it's going to block on remote procedure calls like accessing a DB or accessing memcache and so on. If you see the G-unicorn tuning guide suggests that you just tune the number of processes that you run so that you can get higher amount of throughput. But the problem is that you can do some amount of tuning with your test platform and try to find the optimal number of processes that you need to run to get the best performance but once in production with varying workloads, different requests will take a different amount of IO and CPU and in production it turns out that very well because if you have a large number of processes serving requests and they all either compete for the CPU or they are just waiting on IO. So your load average keeps going up and down. So the solution is of course to use a non-block framework. So this one that lets you do async. So what is other popular looking IO frameworks? So it gives you a synchronous API which starts using existing code. There's no need to rewrite a lot of existing code that has been running. Rewrite is always expensive, whatever kind of work you're doing. I mean if you're a big company or a small company or trying to accomplish something fairly complex, a lot of code that you have already tested for a long time, it's going to take a lot of time and it's fairly expensive. It gives you the advantage of not having to rewrite it. And frameworks like Twilio, Tornado or even the Python 3 async IO framework has the problem that you have to rewrite a bit of the code. In an event driven framework like Twisted you need to rewrite your code in terms of pure CPU and pure IO calls. You have to register your IO calls and then write callbacks so that it will know what to do when an IO operation completes. In other IO frameworks, you need to decorate a lot of your code. You need to mark it as something that needs to be run inside an event loop and so on. The main advantage with G event is that you have to rewrite very little. So what is G event? We're taking a line from their documentation. G event is a coroutine-based network library which means that functions have to be threading aware and when it does an IO call it needs to be able to switch. So how this is done for a vast majority of Python libraries is through something called monkey patching. What happens in monkey patching is that standard library functions like for example the socket library, blocking IO calls in that are replaced by functions which are non-blocking and the IO loop aware.  So what G event does is it has, each process has a G event hub which is an interface to a fast event loop provided by a C library called libEV. Each green light when it needs to do an IO operation will register its IO call with G event hub and when the response comes back the G event hub will wake up the waiting green light. But the best part about all this is that it happens completely under the hood. I mean your code doesn't look like it's doing all this but it does and the performance improvements are quite huge. So how would you use it with a standard web framework like flask or Django? So here's a small code snippet that shows how, I mean how to make your web server blocking, non-blocking. So in this there's just one view function at the URL hello that does time.sleep1 and returns hello1. So when that initial line that imports patch all and then calls patch all just calls make sure that the time.sleep function is replaced with a non-blocking equivalent from the G event library itself and when time.sleep1 is called it doesn't block the whole interpreter and make your web server just wait. So it can process other requests. So the one way to deploy a non-blocking server is to use G event's vizgi server. You can just plug in your vizgi standard web server application into G event's vizgi server and you'll get a process that is, you'll get a web server that spawns green lights for each request and works in an asynchronous manner. So, but one small disadvantage of this is that you can only run one process if you use the vizgi server. A better way is to use the micro vizgi web server or the G unicorn web server and use the G event of worker type in them. This again, this input, this makes sure that each request runs in a separate green light and you can spawn. So how, what it will look like is when you, you can spawn, say, four worker processes, each process, so four should be equal to the number of cores that you have on your hardware and for each, in each process it will spawn some number of green lights which you can configure. And each green light can run simultaneously with the other green lights because during IO it switches green lights. So, but how do you know, I mean, if you have an existing application you have to consider, will it work for my app? So, some things to consider are, is your application CPU bound or IO bound? So, one thing to remember is that if it's CPU bound, G event is not really going to do much for you because it doesn't, it's an asynchronous IO framework. So, it'll make your IO calls non-blocking. But what about if you have some library that does IO in, say, a C layer, that is, which is not using some standard Python library like Socket? For example, DB drivers do that. You need to consider if a green alternator for that is available. Sometimes, more, nearly everything will be fine except that you'll have this one library that does IO in the C layer. So, in those cases you'll have to consider if you can work around it somehow. The problem with a Python library that does IO in its C layer is that it can't be made green light aware at the Python layer. So, like that fourth green light is doing, it's calling a function that does IO in the C layer and that blocks the whole interpreter and you've lost the benefits of an asynchronous IO framework. So, we'll go over what we can do about such situations. So, this is one way. So, a DB driver for Python usually does its IO in the C layer. Like, for example, the Postgres driver PsychoPG2. But it has a green alternative. You just add another library called PsychoGreen and then you call that function and your DB calls are made green light aware and non-blocking, therefore. So, just to show you what, I mean, show you that it works because I've heard that a lot of people have problems getting their DB driver to work well. So, I'm going to show you a small demo. So, the demo is going to basically run two requests multiple times. The first request just calls this function, which is sleepPython, which just calls sleep for five seconds and then returns something from the DB. So, we'll see if time.sleep blocks are not. And the other request that is going to run is to pretend as if the database is doing a lot of processing. But we're just to simulate that, we're just going to call Postgres to sleep for five seconds using selectPgSleep. So, the demo just runs in Docker. I'm just starting the database here and populating it with some dummy data. So, this client program is just going to run five requests of Python sleep and five requests of PgSleep. So, what we see is that though all five requests run simultaneously, the overall time to process all those requests is still very close to five seconds. So, this means that it's non-blocking. So, okay, now the screen is too small. So, I wanted to show you that in this case, the web server running microvisg is running three processes. So, I'm going to increase the number of requests that we make it execute. So, you can inspect the code at my GitHub account. So, I'll show you the link shortly. So, again, you see that it takes just five seconds to do both the Python sleep and the Postgres sleep. Okay. So, yeah, moving ahead. So, now I'm going to, okay, it's not really visible, but let me just show you what it's doing. So, some C libraries, like I said, sometimes most standard libraries, I mean, all your standard libraries are working fine, but you have this one library, for example, LXML, which is, like, I think the fastest XML processing library that you can use in Python. This library uses C layer and sometimes can do blocking calls, like, for example, the parse function is able to accept a URL which it will fetch and then parse and return. But while it's fetching the URL, it's going to block your process. So, one way to work around it is to make it to fetch the data from the URL out of band. That is, do it in a separate call to URLlib.url open. First, fetch that data and then ask LXML to parse it and give you the XML object. So, in this case, yeah. So, this, the actual parsing component is CPU intensive and will block, but in these cases, what you wanted to do is to run continuously. So, for example, if you're using, say, the Python standard threading library to build something like this, it's going to switch even if you're doing CPU intensive tasks or IO intensive tasks. But in such cases, you usually want to let an IO intensive function run completely. Another complication that you might have to consider is if in your view you're calling one CPU intensive process multiple times. Say you pull multiple objects from the DB and you need to, say, read it off as a JSON object or parse XML of it. So, my expensive funk here could be any of those. So, if you need to call it multiple times, it will block other greenlets. That is, other greenlets won't get a turn to run. So, what you do is you call gvent.sleep0, which tells the greenlet to sleep for zero seconds, but effectively gives the gvent hub to switch greenlets. So, this way you can avoid starvation if you don't have too many CPU intensive functions like this. So, that's about how simple it is to use gvent to make your synchronous IO, asynchronous without changing your code much. But what else can you do with gvent? So, the greenlets or the threads that are in gvent, we call them greenlets, they are really cheap. You can spawn hundreds and thousands of them and still your machine won't even get warm. So, you can use these things and some standard synchronization primitives that gvent provides to build complicated multi-producer consumer queues and various other things. So, some standard synchronization primitives that are available are called events and queues and locks. So, I'm not going to go over queues because those are quite simple, but I'll go over an interesting use case that we have at Plevo about that uses events and locking. So, at Plevo we're a call and API, call and SMS API service. So, in the call running component, phone calls I mean. So, in the phone calls running component we have a soft switch called free switch that streams audio to various endpoints that are in a call on your server and how it's controlled is via a socket called which is called the event socket layer in free switch terminology. So, this event here refers to events internal to free switch. So, just to give you an idea of what it's doing. So, a call manager process which we've written is used to send commands to free switch and the commands are like start a new outgoing call or hang up this call or play some audio on this call or connect this call to another call. Various things like that and free switch sends responses to these commands saying okay I'm doing it, no I can't do that or some error or something and additionally it also sends events on the same socket. So, the events can be like there's a call heartbeat that keeps getting generated every few seconds to show that the call is alive so that you can do billing. It will notify you of newly incoming calls so that your call manager process can say how to control it and hang up events, various kinds of events. So, this is how it works. All this happens through a single socket. So, let me show you what the threading model is inside our call manager process. So, the commands sending greenlets, there are many of them each usually one per call and they send commands to control a particular call and they send commands to the free switch event socket layer. All responses by the free switch, both to commands and new events that are generated are caught by a single greenlet that is simply an event listener. Here when I say event listener I mean free switch events but it also listens to command responses. So, the event listener's greenlets job is to root command responses to the greenlets that made those commands. So, you have to send the responses to the right greenlets that made those commands and for events that are generated by free switch it generates new greenlets that handle these events. So, let me show you how this code looks like. So, this function called commander is executed by every greenlet that is trying to send commands. So, that would be those greenlets on the right. So, the arguments T is just a transport object. So, it just encapsulates the socket. CID is the command ID and CMD is just the command. So, we use a couple of shad structures here. One is called commands and it's a deck. So, a deck is just short for a double-ended queue. So, you can insert and pop from both ends. There's a lock also that's used. So, in the code as you can see the first step is to create an async result object. So, this is like a future or a deferred if you're coming from a different set of jargons. So, it's an async result and what it can do is so it can hold some result that will come later on. So, what we do is we append the async result and the command ID as a tuple into the command's double-ended queue and then we call send command which basically sends the command to the event socket. And this we need to do inside a lock. Okay. After this is done, now we call asyncresult.get which basically weights blocks the current green light. So, this is the command sending green light, blocks this green light on waiting for the response. So, the response is received when this asyncresult.set is called. So, we'll see where that is called. The lock is to ensure that the green light that sent a command gets the right response. So, it shouldn't be the response to some other command. That's what we're trying to synchronize here. So, this is the response handling green light. So, this handles both responses to commands as well as events. Okay. So, it's just an infinite loop where it reads the response of the socket object, checks if it's an event. If it is an event, it just spawns a new green light to handle that event. And if it doesn't start with an event, it's a response to a command. So, now you need to wake up the green light that is blocking on this command. So, that will be the first command in the double-ended queue called commands. So, we pop that and call asyncresult.set. So, that will cause this green light to continue from this point. So, you can see a fully runnable example at my GitHub PyCon 2014 repo. I'm not sure how I can make it brighter. So, let me read it out to you. It's just do you want me to read the code out or the link is just github.com slash Donatello, which is d-o-n-a-t-e-l-l-o slash PyCon 2014. So, there are some caveats that you have to look out for when you're working with g-event. I've already mentioned a couple of those, but another one is that it breaks standard profiling tools like c-profile. So, if you already have a lot of stuff set up that helps you profile your code with c-profile, they're going to break. But there are alternatives, but you need to try them out and see what works and there's a green-let profiler there's a green-let profiler project whose author, I think, was planning to speak at this PyCon, but I don't think that happened. With services like New Relic that do say that they will handle I mean, they do handle g-event projects. At least in my experience, it's like sometimes it works, sometimes it doesn't. For some projects it works and for some it doesn't. The other two caveats are simply what I've already mentioned that you need to make sure that libraries that do I.O. in the C layer have green-let-aware alternatives and if you are doing CPU intensive operations, you need to make sure that you don't starve out other green-lets. Yes, so benchmarks. Benchmarks that compare multiple web servers are quite complicated to do and this one is done by someone else and it compares a really large number of benchmarks and large number of web servers that are in Python, so many of them async, some of them sync and it's a pretty well done benchmark. It shows that it does do better than Twisted and many other popular frameworks. That's it. Can I just take any questions? Yeah, web server? So you can use a simple one to use is G Unicorn. You can get it working quite quickly, but for performance, I think you should use microviskey, that is UWSGI. That project is written in C++ and it's way faster than G Unicorn. If you want to squeeze out more performance, you should use microviskey and yeah, it's got a lot of tunables that you can play with to get a lot of performance out of it. Hello? Excuse me? Yeah. In memory Redis server. We just store sessions in Redis and we use load balancer to send HTTP request and we just use Amazon to scale up. Lots of instances behind an ELB all talking to a fast Redis server which shares the session. So it works quite well. I have a question. How do we use Django and we use Celery for a lot of queuing. Can this help out instead of Celery or as a substitute or as some kind of a substitute for Celery? Yeah. It could, but Celery does a lot of things that you'll have to build yourself if you choose to build it with G-Vent. But G-Vent if it's not too complicated what you're trying to do I'm sure G-Vent can do quite well. So we use there ShadQ synchronization parameter. So if you call G-Vent.patch all you can just see the dock of that function. Basically it patches all your standard libraries. The most common ones that you'll be using are sub-process or I mean socket, sub-process and OS I guess. Yeah. Python wasn't yes I think so. Python 3 is not yet supported but I think 2.5 to 2.7 is supported and it works. No, it is necessary to call it inside your application as well because what G-Unicon's G-Vent worker does is it simply creates a G-Vent thread pool a green light pool and simply puts your requests in different green lights but to make your code non-blocking you do have to call a patch all inside. Yeah. It will Yeah, that request will block your web server process until that get completes. So I have a question. Yeah. From the db driver Yeah. MySQL I don't use MySQL much so my knowledge is limited but there is a pure MySQL db driver and there is a c-based driver so the pure one will be non-blocking by default. Yeah. db driver itself will block because that's what so for these kinds of things you need a good profiling tool so I've used one tool called green light profiler which works for I mean which has worked on some projects but it hasn't been a complete solution in my experience. Yeah. So our approach is usually to look at what libraries are linked into the applications and see if those are explicitly known to be non-blocking. Yeah. Yeah. Yeah. Yeah.