Bug 21421 - Uploading large files using HttpClient.SendAsync causes long delays
Summary: Uploading large files using HttpClient.SendAsync causes long delays
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 7.2.6
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2014-07-17 23:18 UTC by Michael Stonis
Modified: 2016-05-25 00:18 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Michael Stonis 2014-07-17 23:18:59 UTC
When uploading a large byte array or stream using HttpClient.SendAsync, after the upload is complete, it will stall for 3 - 10 seconds before reporting back that the upload is complete. 

Performing the same test on Android results in an immediate report of upload complete.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2014-07-18 06:28:26 UTC
This is because of buffering in the kernel.

We give the data to the kernel, and that's when we report the progress. So 100% doesn't mean "everything uploaded to the server," but "everything sent to the kernel."

My guess is that for android the kernel buffer is smaller, which means that the delay between sending the last chunk (and reaching 100%) and receiving confirmation that it's been uploaded is much shorter.
Comment 3 Michael Stonis 2014-07-18 07:54:37 UTC
Any ideas on how to properly report upload progress? The user experience for iOS is pretty bad because of this as it appears that the app pauses for an extended period.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2014-07-18 08:12:56 UTC
I don't think there's a way to be entirely accurate without a substantial rewrite (upload small chunks instead of big files for instance).

I'd probably create some sort of "fuzzy ui", where at the end you something other than "100%" (something like "finalizing upload" and a spinning wheel for instance). This is more of a design problem than engineering problem though.
Comment 5 Michael Stonis 2014-07-18 09:54:11 UTC
Overall, I understand, but is there any way to provide a compiler hint or similar to decrease this time. For a single upload, it is not a big deal. In the case of multiple uploads, even when performed in batch, it adds significant time to uploads. For example, when uploading 10 files on Android, it might take 3 seconds. On iOS, it can take nearly a minute.
Comment 6 Michael Stonis 2014-07-18 10:15:14 UTC
Also, during testing, we have had users report that it takes up to 45-50 seconds to get the completion notification on iOS. Same users using the app in Android on the same network report that uploads only take <1-2 seconds.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2014-07-18 10:49:40 UTC
Uploads should not take longer with the kernel buffering, it should only change the timing of the upload progress events, so it seems something else is going on.

However the timings I have doesn't seem that strange (~3s to upload the 1.1mb of content both in the simulator and on device) considering my internet speed.

Could you modify your test case so that it shows the slowness clearly as well?
Comment 8 Sebastien Pouliot 2016-05-25 00:18:18 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!