Now, we can run the drone_service.py script, which launches the development server for Tornado 5.1.1 to our new version of the web API that uses the non-blocking features of Tornado, combined with an asynchronous execution. Make sure that the drone_service.py script is not running anymore. Execute the following command:

    python async_drone_service.py

The following line shows the output after we execute the previous command. The Tornado HTTP development server is listening at port 8888:

    Listening at port 8888

In our new version of the API, each HTTP request is non-blocking. Thus, whenever the Tornado HTTP server receives an HTTP request and makes an asynchronous call, it is able to start working on any other HTTP requests in the incoming queue before the server sends the response that the first HTTP request is received. The methods we coded in the request handlers work with an asynchronous execution and take advantage of the non-blocking features included in Tornado, combined with asynchronous execution.

In our previous example, we executed three HTTP PATCH requests to set the brightness levels for the red, green, and blue LEDs. We will run them again with the same Windows configurations we used before to understand how our new version of the API processes three incoming requests.

Use the history features for the Terminal, Command Prompt, or Windows PowerShell window to enter the commands again in each window that executed the previous HTTP PATCH request. As we did before, do not press Enter yet, just leave the commands written.

Now, go to each window that has the commands to compose and send the HTTP PATCH request, from the first to the third window and press Enter quickly in each of them. You will see the following lines in the window that is running the Tornado HTTP server:

    I've started setting the Red LED's brightness level
    I've started setting the Green LED's brightness level
    I've started setting the Blue LED's brightness level

Then, you will see the following lines, which show the results of executing the print statements that describe when the code finished setting the brightness level for the three LEDs:

    I've finished setting the Red LED's brightness level
    I've finished setting the Green LED's brightness level
    I've finished setting the Blue LED's brightness level

The server could start processing the request that changes the brightness level for the green LED before the request that changes the brightness level of the red LED finishes its execution. In addition, the server could start processing the request that changes the brightness level for the blue LED before the other two requests finish their execution.

The following screenshot shows four Terminal windows on macOS. The window on the left-hand side is running the Tornado 5.1.1 HTTP server and displays the messages printed in the methods that process the HTTP requests. The three windows on the right run the http command to generate the HTTP PATCH request that changes the brightness level for the red, green, and blue LEDs. It is a good idea to use a similar configuration to check the output while we compose and send the HTTP requests and understand how the asynchronous execution works on the new version of the API:

Each operation takes some time but doesn't block the possibility of processing other incoming HTTP requests, thanks to the changes we made to the API to take advantage of asynchronous execution. This way, it is possible to change the brightness level for the red LED while another request is changing the brightness level for the green LED. Tornado is able to start processing requests while the I/O operations with the drone take some time to complete.