 Hi, I'm Victor Steiner and I'm very happy to present to you the AsyncIO community one year later So my name is Victor Steiner. I'm a Python core developer since five years now And I am a senior software engineer at Redats My job is to port OpenStack to Python 3 Which is working well. We are close to having a Python 3 support And I'm also working on the Novrat project, which is a virtualization part of OpenStack And I'm working remotely from the software friends for me the launch of AsyncIO was in March 2014 With the release of Python 3.4. It was the first time that we it was widely available to users and At this time it was bare You had almost no libraries, which means that you can write a short yellow world but it's really hard to develop an application on top of AsyncIO because Basically, it's like you only have the socket modules, so you don't have HTTP. You don't have You don't have anything. So what's the community today? For me the main point, central point is a PythonChillip mainline list Which is a Google group? We use the list to discuss new features, to discuss bugs, to discuss the behavior of AsyncIO Because the module is still young and we still sometimes have issues with the design or subtle behavior It's also used to get help on AsyncIO because we don't have great documentation, so some people still have questions on how to write an asynchronous application Recently, we had to move from a code that's Google.com because the site is a closing We moved to GitHub and I hope that GitHub will bring us more pull requests because it's easier to fork the project and to send a pull request So you can use this website to report bugs But we also have the Python bug tracker since AsyncIO is now part of Python language of the standard library And obviously we have more and more conferences. You may have seen that at European we have five conferences about AsyncIO To start on the libraries, for me the most famous one is the IOHTTP. It's very famous It's the most successful library It's not only an HTTP client, but it's also an HTTP server Obviously it supports the HTTPS for SSL on TLS security And you have also web sockets, clients and server And it has a nice documentation on the readthedocs.org To show you a short example, that's the most basic example for HTTP requests You create a request using the get verb, you pass the URL and you get a request On this object you have attributes like the status to check that the request was successful And you can get the content of the body using the read method In fact it's very close to existing libraries And for me the API is not surprising, it's easy to use And I put the part specific to AsyncIO in grey just to focus on the API But obviously when you do something asynchronous like fetching data from the network You have to put yield from in front of each core Like creating the request and getting the body of the request And you have to decorate the methods using I think IO.co routine For databases, for SQL, you have a client for MySQL, which is IO MySQL For Sposgress you have the IO-PG driver which is based on the Psycho-PG too So it's not completely new, it's just a wrapper to have an API compatible with AsyncIO on top of Psycho-PG too The API is not new, in fact it's just a Python DB API adapted to AsyncIO And this example creates a pool of connections A pool of connections is something more specific to progress But it's more efficient because you can send more requests at the same time But you can also create a single connection if you prefer From the pool you create a cursor A cursor is a standard method of the DB API You use execute to execute your client And fetch one is used in this example because it's very short to only fetch one row And at the end you get your number one And since every thing is asynchronous, you have to put yield from in front of each method call But if you ignore the yield from, the code physically looks like a blocking call If you don't want to write directly SQL query, you can use an ORM like PeeWe PeeWe is a wrapper called PeeWe Async Which is the AsyncIO layer on top of PeeWe to have the asynchronous API And for SQL Alchemy, you have IOPG.SA Which is not the full API, it only implements a part of the API Especially you don't have the lazy part The lady loader For key value stores, we have three drivers For memcached you have IO memcache For redis, you have two clients, IO redis and AsyncIO redis And for me, it's not a bad thing to have two drivers for the same thing Because depending on your background, depending on which API you prefer You may take IO redis or AsyncIO redis And maybe later one will die Or maybe the two will continue At least you have the choice And we have a client Short example using IO redis In this example, we wait for the result of each command So we get the value of full And directly you get the result You increase the value of bar and get the result So in this example, it's like you are blocking until you get the result But you can do better using IO redis Since it's a coroutine, you can schedule a task in the background to get a value Schedule a second task to increase the value of bar And later wait until both tasks are complete And using that, it's more efficient because the server calendar more requests at the same time And using that, you can expect more better performances thanks to AsyncIO And thanks to the design of IO redis And this API is called Pipeline And in my example, I use the standard AsyncIO functions gator But you can also use a redis function which is called Pipeline To do basically the same with a shorter syntax For NoSQL, you also have clients For CoachDB, you have IO CoachDB For MongoDB, you have AsyncIO MongoDB So basically, you have everything to access all kinds of databases Which is much better than the state one year ago when you had nothing to build an application For clients, we have more standard network protocols like DNS and IRC I didn't route the full list of clients because the list is quite long I tried to focus on the most common protocols For DNS, it can be a bottleneck on your application because DNS is quite slow compared to an application So it's a good thing to have a asynchronous resolver Currently, in AsyncIO, we are using our thread In fact, a pool of threads to run the blocking functions resolving a name But in IO DNS, it's really asynchronous, it uses non-blocking sockets So it's more efficient For IRC, you have two libraries, which are bottom and IRC-free So as I said, it's up to you to test both libraries to decide which API do you prefer For SSH, you have Async SSH, which is a library fully implemented in Python for SSH So you have a fine control on the SSH protocol and how the connection is established For XMPP, for Java, you have a slick slide XMPP, which is a fork of slick MPP And as I said, we have much more clients for less common protocols like IMI For Asterix, you have the panoramics project to use on the Asterix telephony server You have IMQP, which is a messaging queue protocol With the module IO-IMQP For ElasticChurch, you have a client called IOES, ATCD, IO-ATCD And Google Hangouts, there is even a client for that called Hangouts I didn't have time to test all these libraries, so I cannot answer to all your questions But I tried to give a long list to show that whatever you want to do with Async IO, you have the right choice of libraries And now for the web framework, we have a long list As you may expect because each people want to write their application differently So you have IO-Pyramid, IO-WSVI, Interest, Muffin, Natural, Pulsar, Rainfall on base And the last one, API-Aware It's not really a framework, it's more a worker to execute the application on multiple cores Because by default, when you use Async IO, everything is in run thread, in run process It's quite fast, but it can be much faster if you use a multiple process So API-Aware is based on G&Econ with a specific worker And you are able to use multiple processes So the clients are distributed between each process and you get much better performances And for your information, Pulsar also works on Twisted on Tornado And Trollus, if I recall correctly So using Pulsar, you can write code working on different event loops For web sockets, you also have a choice between four libraries IO-HDTP, as I said, has a module for web sockets For client and server You have Autobahn Python, which is also compatible with Twisted, Tornado and Trollus I will explain Trollus later And you have also web sockets on web sockets for Python And it's also interesting to write servers Because Asynchronous programming is very efficient for network servers And currently, for me, the list is quite short We only have four supported protocols I hope that next year the list will be much longer The first one is FastHGI, which is a protocol for Asterix telephony server Called Panoramisk For IRC, we saw the IRC-free module In fact, it has a sub-module called IRC-freeD Which is the implementation of the IRC server For HTTP, you have IO-HDTP Which is the most used implementation of HTTP server for AsyncIO And for SSH, you also have a server called Async-SSH This is the most simple example of an hello world using IO server To write a very basic server You define an handler for a request And you have to build a response object with the body hello world Which is here by string And you create an application And you connect the handler to a new URL using a router But you may have seen that the handler is a coroutine So, since it's a coroutine, you can use any AsyncIO task or feature For example, here I'm using a GetStatE-Portical function to get statistics So you can run a long process in background and return the result later For tests, you have the choice between two libraries For me, it's very important to test code, especially in the asynchronous world Because when you are using the network, sometimes it's quite fast, sometimes it's quite slow So it's important to have a stable test to always get the result And ensure that you don't have regressions And AsyncIO has a specific API which is not very easy to use using unit tests So using these two projects, you have some helpers to test very easily the behavior of your asynchronous functions The first one is AsyncTest, which is more specific to AsyncToUnitTest And PyTestAsyncIO, which is more specific to PyTest And there is even a third one, which is ioTest That's my project which I wrote to test an implementation of AsyncIO The idea is to check that you implement all methods of AsyncIO And you conform to the AsyncIO specification that you have the same behavior on any implementation of AsyncIO So now we come to Trolleus Trolleus is a Python 2 port of AsyncIO I wrote this project to try to replace eventlets with AsyncIO in OpenStack The issue is that OpenStack is currently only compatible with Python 2 So the idea was to port AsyncIO to Python 2 first to be able to replace eventlets with Trolleus And the main issue is that yield from syntax was added to Python 3.3 So if you use this syntax, it doesn't work directly because you get a syntax error And to solve this issue, I chose to use the yield keyword using a function called from with uppercase f And the idea is to have code which looks like AsyncIO, but which is compatible with Python 2 The main issue is that since syntax is different for coroutine, you only have a few libraries which are compatible with Trolleus yet Sometimes you have to duplicate the code or you have to write some specific code for Trolleus For this reason, I suggest you to try to first port your project to Python 3 And to use AsyncIO because AsyncIO is more popular and it has a wider choice of libraries So only use Trolleus if you cannot support your application immediately to Python 3 So benchmark Ludovic Gask has good news for us He ran a benchmark on his use case He compared a flask Django on Happy Hour Happy Hour is based on AsyncIO And as you may know, it's very difficult to understand benchmark results You should not rely on this result because as always it depends on your use case How you use AsyncIO, how you run the worker, how you connect with your database But at least we have one specific case for the application run by Ludovic And the good news is that Happy Hour is fast, as fast, so it's not slower For me, it was not obvious that AsyncIO was not slower And the very good news is that in some cases it's much faster In the best case, Happy Hour handles 5 more requests per second Which is quite huge And for the basic example of a G-sensor realisation It handles 400,000 requests per second using Happy Hour But Django and Flask handle 70,000 requests per second So it's much faster just by writing your application differently But as I said, you should go to the blog to get all the details And Ludovic told me that someone else ran a benchmark on a different use case So you should go there to get all the details and compare numbers And maybe run yourself the benchmark on your hardware to check if you get similar results And finally, how can you help? In my opinion, the bottleneck of AsyncIO is the lack of documentation I spend a lot of time working on the documentation, but it's a reference for the API It's not really something for beginners And in my opinion, we need a tutorial starting from the very beginning From a coroutine, what is a coroutine, what is a task, what is a future How to put all the pieces together and really start step by step Because if you take the client documentation, it's really hard to build an application just using this doc So we need tutorials but also more documentation in general And maybe a cool project would be to try to port standard libraries to AsyncIO Because we have a lot of protocols which are not supported yet So FTP, POP, IMAP, NNTP, SMTP, Telnet, XMLRPC, etc So it should not be so hard but we just don't need a volunteer to do the job And I'm surprised because for Twisted we have no interoperability layer I'm surprised because we have layers for Eventless, G-Event, Tornado, Jlib, Qt, TCLTK In fact, all existing Eventloop except top of Twisted I already tried a few months ago, I had a proof of concept and it worked So we just need a few lines of code to be able to use AsyncIO on top of Twisted Or the opposite, to use Twisted on top of AsyncIO And for me it would be great to be able to use both in the same application Because even if we have a long list of supported protocols, Twisted still have much more server protocols Much more clients and very good base which is tested since last 10 years So Twisted is still useful for many cases To finish, I give you two links The first one is a list of all resources around AsyncIO It's a list of clients, the list of servers, but also list of talks List of documentation, list of benchmark, everything around AsyncIO So it's a good starting point if you would like to find anything around AsyncIO And the second link was my main source for this talk It's a list of all clients, all servers, but also all libraries for AsyncIO Like you have a library also to under the disk, so accessing files in a asynchronous manner And you have a very long list, so go to the link So thank you, and do you have any questions? Thank you for all the good overview Do you foresee any problems in terms of compatibility with PEP 492 in Python 305 Because as Guido, I'm also kind of excited about the new await Is there any kind of problem you foresee? The question is about the new PEP for Python 3.7 Which introduced two keywords, Async and Await The PEP was written by Yuri, which works on AsyncIO So he knows AsyncIO and he didn't want to break the compatibility The PEP was written to be compatible So it will be possible to write code using the new keyword and continue to use existing code So there's obviously a lot of excitement around AsyncIO And everybody is writing web servers in it and using it for handling, obviously, network traffic But I've seen some blog posts about that it's not as feasible as people would think For everything, for exactly IO bound applications Still sometimes are more performant, even with Python threads Because there's supposedly a lot of overhead for the loops And how do you see it? Because obviously you have a lot of experience with AsyncIO So how is it in terms of performance as of now? So the question is for CPU bound code So as I said, nope Even IO bound supposedly is sometimes faster with threads still But I didn't do the research, I only read stuff on the internet I'm not aware of bottleneck for IO bound So I cannot answer for IO But it's very efficient to handle code asynchronously because you are able to execute tasks in parallel So it's much faster But if you have some articles just send me an email and I will try to answer So hi How often do you run into problems when writing code using AsyncIO? Running into third-party libraries which are non-cooperative and do stuff somewhere where they do blocking operations like a DNS request How often is that a problem? The question is for blocking code in existing third-party libraries The most obvious answer is to use as threads Because it's already what AsyncIO uses for DNS We use a pool of threads so you can execute whatever you want It will not block the event loop And the second question was how often we have such code? So I'm asking because I know G-Event had G-Event monkey where it would monkey patch a bunch of standard library stuff to get you around this problem Because sometimes you don't even realize that a library you might be calling might be doing blocking operations So if you have some experience, how often is that a problem? I don't have a long experience in large application using AsyncIO so I don't have a simple answer But what I can say is that in AsyncIO you have a configuration option saying that if your function takes more than 100 milliseconds You get a warning saying that be careful the function blocks your event loop Or maybe you have to split your function or use something asynchronous So at least you have a warning Hi Victor, about writing libraries which is important like in AsyncIO Redis The two libraries use Redis for the framing and they both know handling or handle connections So that's very important to just focus on the implementations of the loop The other statement is more about running something in a thread There is a running executor to run something in a thread directly with AsyncIO So thank you for your talk I'm not sure that I understood your question You say that some libraries are still using threads? No, there are two things Redis, the two libraries, use iRedis iRedis is a C module to implement the protocol So they focus on writing a client using AsyncIO And when you have CPO bound code you can use running executor to run your code into a thread directly by the loop And the question more is like how can I know that I'm not doing bad pattern with AsyncIO Is there some good practice or something to new developers to understand correctly AsyncIO? The main idea is that you must never block the event loop So it's really a bad idea to get to call a blocking call And when you take a random library it's not possible to know in advance if you will block for too many time So as I said you have parameters to detect such slow functions But maybe you have to dig into the library to read the source code I don't have a simple answer for that But there is nothing like monkey patching because we want to explicitly say that at this position we are running something asynchronous It's part of the design Okay, one more quick question First of all, thanks for your talk So just a little follow up question Redis is actually a very good example of something that is so fast That if it runs at least on the same hosts I have doubt that asynchronous execution will bring any effects as compared to just waiting for the response on the local host And because of this my question to you is do you have any view on this? In what cases would the overhead of scheduling callbacks and event handlers on the event loop of async.io pay off as compared to if you would just wait for the response of the particular application on the socket How big is this? Okay, now there is no simple answer for that It depends really on your workload But the idea behind async.io is not to send the answer as soon as possible to the clients The idea is more to handle a lot of concurrent clients And using this design of the event loop and having a task which are running in background The idea is to support a high workload with a lot of concurrent clients And I hope that you will be able to handle more clients And your question was should we use blocking code or asynchronous code? I think that you should write a benchmark and try with different kind of clients depending on how you use the library, how many requests you send, how many concurrent clients I don't think that there is a single answer to your question It depends on your use case and workload Okay, thank you Victor