You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Today session.get_credentials() and session.create_client() don't use a lock when sourcing the credentials. This results in a performance problem when multiple AWS clients are created concurrently and awaited with asyncio.gather. This is a real-world problem when the script runs in an environment that uses credential_process that takes an exclusive file lock. For example, it reproduces in my real environment that uses aws-vault SSO config with pass backend.
Here is a minimized reproduction of the bug. Take this Python code as an example (it doesn't close the AsyncExitStack, but that's irrelevant):
Put the following bash script into /tmp/cred-process.sh and make it executable. This script takes an advisory file lock on /tmp/lockfile and imitates the delay of 0.5s of resolving credentials (just like aws-vault with SSO setup has considerable delay):
Now if you run the python code with asyncio.gather(), it'll take ~3 seconds to execute. This is because every create_client future invokes its own credential process, and waits for 0.5 on a file lock to be released. If you call await session.get_credentials() right before asyncio.gather() then the runtime decreases to ~0.6 seconds.
So the problem is that the credential loading process is not locked, and multiple futures try to spawn their own credential process when the credential cache is empty, thus resulting in a significant lag.
Checklist
I have reproduced in environment where pip check passes without errors
I have provided pip freeze results
I have provided sample code or detailed way to reproduce
I have tried the same code in botocore to ensure this is an aiobotocore specific issue
I have tried similar code in aiohttp to ensure this is an aiobotocore specific issue
I have checked the latest and older versions of aiobotocore/aiohttp/python to see if this is a regression / injection
this is the same thing in botocore if you create multiple botocore clients in different threads. We basically just parallel what botocore does. I'd log there with the threading equivalent, when they do it there we'll do it here :) Note we follow this pattern with refreshable credentials: botocore vs aiobotocore. But please do double check with botocore and threads.
Describe the bug
Today
session.get_credentials()
andsession.create_client()
don't use a lock when sourcing the credentials. This results in a performance problem when multiple AWS clients are created concurrently and awaited withasyncio.gather
. This is a real-world problem when the script runs in an environment that usescredential_process
that takes an exclusive file lock. For example, it reproduces in my real environment that usesaws-vault
SSO config withpass
backend.Here is a minimized reproduction of the bug. Take this Python code as an example (it doesn't close the
AsyncExitStack
, but that's irrelevant):Then create an AWS config with the following profile:
Put the following bash script into
/tmp/cred-process.sh
and make it executable. This script takes an advisory file lock on/tmp/lockfile
and imitates the delay of0.5s
of resolving credentials (just likeaws-vault
with SSO setup has considerable delay):Now if you run the python code with
asyncio.gather()
, it'll take ~3 seconds to execute. This is because everycreate_client
future invokes its own credential process, and waits for 0.5 on a file lock to be released. If you callawait session.get_credentials()
right beforeasyncio.gather()
then the runtime decreases to~0.6
seconds.So the problem is that the credential loading process is not locked, and multiple futures try to spawn their own credential process when the credential cache is empty, thus resulting in a significant lag.
Checklist
pip check
passes without errorspip freeze
resultspip freeze results
Environment:
3.10.12
22.04.5 LTS (Jammy Jellyfish)
The text was updated successfully, but these errors were encountered: