-
Notifications
You must be signed in to change notification settings - Fork 886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S3 uploads are 2 - 3 times slower in IOS compared to Android. #2434
Comments
Hi @chandusam2002 interesting testing on performance using different clients. I was going to suggest trying to use S3 client directly to see if that improves the performance but it sounds like there is very little difference. The S3 client is the thinnest client we have to interact with S3 service so if the round trip time of the request isn't improved, there isn't much the SDK can improve on and would be something we can take as an enhancement to perhaps improve the AWSCore which contains a lot of the networking classes that are used across all SDKs. i've heard there is this feature called "transfer acceleration", I'm not familar with it but sounds like worth a look https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html |
Thanks @lawmicha . I will run tests with transfer acceleration to see whether it improves performance. |
I'm seeing the same issue. A simple PutObject for an 800 KB file will take ~2s using the Android SDK and around ~5s using this SDK. I am using the API in the Android SDK that takes in a File however, while the iOS SDK does not appear to have an equivalent. Maybe there's something going on in the Android SDK that makes the file streaming more efficient, or something strange about how the content field is being read in the iOS SDK. |
Seems more likely that it's due to how the SDKs connect to S3. This SDK uses the deprecated https://s3.amazonaws.com/{bucket}/{key} URI and the PUT HTTP verb, while the Android AWS SDK uses the more up-to-date https://{bucket}.s3.amazonaws.com/{key} URI and may have some optimizations around how it connects. What's interesting is that their performance is similar when I connect to a us-west-2 bucket (I am in Washington), but if I connect to a us-east-1 bucket Android far outstrips iOS. |
I am also facing the same issue. Is this issue fixed ? |
Is this related to sessions being configured as background sessions? https://github.com/aws-amplify/aws-sdk-ios/blob/main/AWSS3/AWSS3TransferUtility.m#L441 Is there a way to configure this to be foreground sessions when appropriate? Though I suppose this only applies to TransferUtility, whereas this issue seems to exist for bare S3 clients as well. I also only see a way to configure transfer acceleration while using TransferUtility, and not on the bare S3 client, which means I'd maybe be taking a step backward if I wanted to use the S3 client for its foregrounding. So I suppose I'd like one of:
|
In the intervening time since this issue was opened, we updated the S3 SDK to use virtual host-style S3 endpoints for the S3 client. It would be interesting to hear if you are still seeing a performance difference using direct S3 client access. However, as @kylelin47 points out, the AWSS3TransferUtility hands off all transfers to a background NSURLSession, which may have some impact on performance since iOS can manage the priority of background operations. In addition, the TransferUtility already used virtual-host style URLs even before the SDK change, so I would not expect the virtual host change to impact TransferUtility. |
That's good to know. I would like to use the S3 client directly, but last I checked I was not able to enable the use of transfer-accelerated calls. Has this been added to the SDK/always existed and I missed it? |
It probably wouldn't have worked before the change to support VHost style URLs, but I have verified that transfer acceleration does work using the S3 SDK. See #3460 for a newly-added integration test that demonstrates it. Hope this helps. |
🔥 I'll try it out! |
Closing this ticket due to no activity. |
Hey guys, Did you find any solutions for this issue. Please let me know so I can use same solution. |
Same with 2.26.1 and iOS 15 |
Same with 2.26.5 and iOS 15. |
on iOS 14 same image uploading within second but on iOS 15.4 same image take a too much time to upload with same code |
Same in 2023. The upload speed is not consistent. Sometimes it's quite ok, sometimes 2-3 times slower. |
@EugeneNaloiko which version of AWS SDK iOS are you using? This was fixed with 2.31.1. |
2.19.1. Hmm, strange, didn't define the exact version, but it's not getting updated to latest automatically on pod update. Thanks, will try out newer one. |
Describe the bug
IOS S3 uploads(using TransferUtility/S3 Client) are slower compared to Android. Upload with size 8 MB takes anywhere between 20 and 30 seconds(on a wifi connection) where as the same upload is taking 7 - 9 seconds on Android.
3 MB upload is taking between 15 and 20 seconds.
I understand that IOS is different and uses NSURLSession to submit uploads. But the performance difference is too big.
** Additional Details**
Downloads are taking slightly longer on IOS but the difference is smaller compared to IOS. This behavior is observed over a long period of time over difference devices.
We use https://github.com/aws-amplify/aws-sdk-android for Android.
Which AWS service(s) are affected?
S3 uploads using either TransferUtility or S3 Client.
Expected behavior
Upload performance is similar to Android.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment(please complete the following information):
Device Information (please complete the following information):
Additional context
Tried using multipart uploads and S3 client and there is very little difference in the overall performance.
On Android side using a ByteArrayInputStream instead of writing to a temporary file has improved the performance. I see that IOS writes the Data object to a temporary file. Not sure whether that is causing the increase in latency.
The text was updated successfully, but these errors were encountered: