Library support and example for async calls

[coffenbacher]

When making a large number of transactions on separate Azure Table partitions (precluding batching), it is difficult to do concurrently and is therefore very slow. It would be great to have official library support and / or examples for this.

Here are the options that I looked at:

requests-futures: The method that worked for me in the end was replacing the _http.httpclient with Requests-Futures, which was really easy to use once implemented and ended up increasing throughput per process by 10x. (However, I only use a tiny slice of the library so my implementation is hacky.)

gevent: The library is seemingly incompatible with Gevent monkey patching (my usual method) due to an SSL issue that I couldn't debug easily.

Twisted / Tornado: I tried their async methods but without rearchitecting my app just for concurrency on inserts I wasn't able to make this work.

Threading: Not ideal due to thread overhead...

[huguesv]

Thanks for the feedback!

I was wondering how long it would be before we start getting requests for some type of async support, and I'm glad it's happening! Hard to justify working on stuff that is not requested...

We're in the process of (once again) implementing a new python code generator + new runtime, so it's great timing and it's definitely something we'll need take into consideration. Thanks for listing the options you've looked at.

Out of curiosity, which Python version are you using? If we were to have native support for 3.5+ async/await, would you be able to use it?

[coffenbacher]

Great to hear! Yes, consider this HIGHLY requested by my team :+1:

(We deploy microservice-sized workers in Docker containers, so we're usually flexible in terms of versioning - at the moment we run a combination of 2.7 and 3.4. Native support for 3.5+ async/await would work great for us.)

[Korijn]

:+1:

[huguesv]

I've done some tests with aiohttp (https://pypi.python.org/pypi/aiohttp) and that seemed to be a good library to use. It's basically the 'requests' equivalent for asyncio that we need.

We're currently testing our newly rewritten AutoRest Python code generator. https://github.com/Azure/autorest/tree/python

Asyncio support won't be part of the initial release. We're focused on getting generated code that works across all Python versions. Once that is out, adding asyncio will be at the top of the list.

[lmazuel]

HI,

Just to give some news, as @huguesv said the new AutoRest Python generated code is finally released with the 2.0.0a1 version. No specific code about async inside, but if you have time to look at the version and give feedback, it would be awesome!

Thank you!

[chhantyal]

Hi, looks like this is quite a old thread. I was looking to make async call and ended up here.

We would really appreciate if there is support for at least asyncio as we usually deal with large amount of data and it would help us a lot in regards to performance.

[lmazuel]

Hi @chhantyal , thank you for the feedback. We unfortunately don't have the opportunity to prioritize this work for now :(. But keeping this issue open as a remember, and we know this is important!

[atpalmer]

I am also highly interested for the sake of a large-scale project I am prototyping in Python (3.5). I'm in the process of considering how the production system will be coded. If async library support were available for Python, that would weigh Python very favorably in our language decisions. We may end up coding some services in Node.js, some in C#, etc. which isn't necessarily our ideal.

[lmazuel]

Hi @parker-andy , thank you for your comment, the more people ask, the more simple it is to do it :)

[Korijn]

still interested !

[prokopst]

I'm interested as well, mainly in asyncio sdk.

[silencev]

I'm interested too. Our project is managing large number of resources in Azure. Need to have asyncio support for lower overhead of threading model

[lmazuel]

Note that this is a real topic we discussed regularly. We made a brainstorm meeting with the requests team, (at PyCon) and they plan for the end of the year to release requests 3.x with async support. This is I think the latest blocking point we have to do it for real.

[atpalmer]

Thanks, @lmazuel for the update. I have considered forking azure-sdk-for-python and essentially replacing requests with aiohttp, although (as you realize) it wouldn't be a trivial task.

Just a note to other developers: I have written some Python code to interact directly with Azure's RESTful APIs using aiohttp, which adds development overhead, but, for some, may be an alternative to the Azure Python libraries.

[RobertoPrevato]

Hi everbody, I did, too. I am interested in using Azure Storage for my Python applications, and I am actually willing to alter the official Azure Storage SDK to support asyncio. I just published an article in my blog about this topic and a fork in GitHub: https://github.com/RobertoPrevato/azure-storage-python. For the time being I only tested 5 functions of the Blob Service (list_containers, get_blob_metadata, list_blobs, set_blob_metadata, create_blob_from_text).

@parker-andy, I understand that you are interested in the full Python SDK, while right now I am interested in the simpler task of editing the Azure Storage (and CosmosDB) SDKs for Python.

Maybe we could join forces?

[lmazuel]

@mayurid @johanste FYI Hi @RobertoPrevato. I read your blog post and you are taking exactly the same approach as I do right now :). We are close to be able to propose every packages on this repo with async and aiohttp. A few details needs to be double tested correctly (like your proxy or headers issue). Note that I'm not talking about azure-storage right now, but you might want to discuss with @zezha-msft from the Storage team or at least start an issue thread on their repo. You have valuable feedbacks since you worked on this!

[zezha-msft]

Thanks @lmazuel!

Hi @RobertoPrevato, great work on the proof of concept! And it's awesome that you wrote everything down with such detail. Your blog could also serve as a great example for modifying the Storage SDK. 😄

FYI we do have an item in our backlog to create a new async version of the Storage SDK, which will not only support asyncio, but will also feature a new design, as well as leverage Autorest-generated code. Unfortunately, we have not started this work item yet. However, I will share your blog and this thread with my team, to prove the community's interest in the async library. Perhaps we will be able to prioritize this work.

In the mean while, I encourage you to continue in this effort, and others to join you. I will update this thread if I have any news. Thanks!

[RobertoPrevato]

Hi @lmazuel, @zezha-msft I'm really happy to receive your positive feedback. :) And thanks for taking the time to read my post and write here. If possible, I am interested in contributing to the async version of the Storage SDK, when you will start working on this work item.

Before that time, I think I will continue working on my fork. Thanks!

[lmazuel]

If you wish to use async in this SDK, @annatisch wrote some instructions how to use our SDK generator from the work in progress branch: https://github.com/Azure/azure-sdk-for-python/issues/2374#issuecomment-380132318

Note that it's highly experimental for now :)

[Petermarcu]

Just an update and I think at this point we can close this issue. We're actively working on adding async in our latest revisions of the python libraries. Here is the latest announcement. https://azure.github.io/azure-sdk/posts/2019-08-06/python-preview2.html . If anyone would like to help contribute to this work, let us know. @annatisch has been working on the async API's for storage.

[RobertoPrevato]

Hi @Petermarcu, thanks for the heads up. I would like to contribute, but I am especially interested in Azure Storage Table Service; which I imagine should be covered by azure-cosmos package now?

But I cannot find recent examples with Azure Storage Table Service in its preview documentation.

To interact asynchronously with Storage Table Service I am currently using a modified version of the official Python SDK to use an asynchronous http client instead of the synchronous one (I did this with three async client implementations: aiohttp, httpx, even my own http client in blacksheep).

[Petermarcu]

Hi @RobertoPrevato , we're currently working on a plan for Tables. I don't know what that will be yet but I hope to know soon. Once we know, I hope we can get something out fairly quickly.

[mwheatfill]

@Petermarcu is there any plan to add async to the Network components? We are currently deleting a large number of routes from route tables and it takes significantly longer than PowerShell.

[Petermarcu]

We're looking at async across the board for python. @johanste

[johanste]

@mwheatfill, out of curiosity, how are you deleting the network components today? And what are the types (for example, are they related/require things to be deleted in order)? One fairly common "fix" to the problem is to simply not get the result for any long running operations and start multiple requests in parallel - at least for long running operations.

[mwheatfill]

@johanste

My customer is using the following in a loop that iterates through each subscription and each route table to delete routes.

async_route_delete = network_client.routes.delete(rt_wrk_dict[rt_name], rt_name, rname.name) async_route_delete.wait()

Is there a supported method in Python that exposes the ARM REST Async capability?