Bug 58638 - AndroidClientHandler is very slow for large files
Summary: AndroidClientHandler is very slow for large files
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 7.3 (15.2)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Marek Habersack
URL:
Depends on:
Blocks:
 
Reported: 2017-08-08 07:50 UTC by Rupert Rawnsley
Modified: 2017-08-09 10:57 UTC (History)
3 users (show)

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


Attachments
Demonstration project (33.84 KB, application/zip)
2017-08-08 07:50 UTC, Rupert Rawnsley
Details


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 for Bug 58638 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Rupert Rawnsley 2017-08-08 07:50:50 UTC
Created attachment 24077 [details]
Demonstration project

AndroidClientHandler is much slower than HttpClientHandler when downloading large files. For example, a 5MB file downloads in 11 seconds for the former and 3 seconds for the latter. For a 1GB file the HttpClientHandler completed in 43 seconds and I gave up on the AndroidClientHandler after 20 minutes.

One obvious difference is that AndroidClientHandler is limited to returning 8192 bytes per call to ReadyAsync (2048 on some devices), whereas HttpClientHandler can grab much more. I can't see any way to influence this.

An example project is attached that demonstrates the problem. Output from a Pixel phone running Android 7:

HttpClientHandler
==============

Downloading: http://ipv4.download.thinkbroadband.com/5MB.zip...
Found download target
Read: 269052 bytes
Read: 1448 bytes
Read: 91224 bytes
Read: 1448 bytes
...
Read: 26064 bytes
Read: 39096 bytes
Read: 18824 bytes
Read: 12980 bytes
Read: 0 bytes
Download took: 2.408798 seconds

AndroidClientHandler
================

Downloading: http://ipv4.download.thinkbroadband.com/5MB.zip...
Found download target
Read: 7916 bytes
Read: 8192 bytes
Read: 8192 bytes
Read: 8192 bytes
Read: 8192 bytes
...
Read: 8192 bytes
Read: 8192 bytes
Read: 8192 bytes
Read: 276 bytes
Read: 0 bytes
Download took: 11.009349 seconds

[Crossposted from https://forums.xamarin.com/discussion/100716/androidclienthandler-is-very-slow-for-large-files]
Comment 1 Jon Douglas [MSFT] 2017-08-08 15:38:08 UTC
I'm *somewhat* able to reproduce. However it's not as drastic as your case.

HttpClientHandler

5mb - Download took: 6.065297 seconds
1gb - Download took: 254.349307 seconds

AndroidClientHandler

5mb - Download took: 4.610711 seconds
1gb - Download took: 321.208145 seconds

Unfortunately this doesn't really help confirm any theories fully. I tried this twice with each handler and the results were the same give or take ~1s on 5mb and ~15-20s on 1gb.

Tests were done with a Nexus 5 running API 23. I am going to CONFIRM this bug off the basis that there is a significant difference in a larger download which is what this bug report captures. Thank you for the report!
Comment 2 Rupert Rawnsley 2017-08-08 15:45:50 UTC
Thanks for the quick response Jon. I've seen it on two devices: my Pixel and an RK3288-based device. On the Pixel the AndroidClientHandler was clamped to 8192 bytes and on the RK3288 it was 2048 bytes. Not sure if this is cause, symptom, or irrelevant, but you might want to check that on your end as well. The reporting line is commented out in the example project.

Also I've got crazy high bandwidth here, so it might be worth running the same test to a local file server in case it is exaggerated by high network speed.
Comment 3 Jon Douglas [MSFT] 2017-08-08 16:09:28 UTC
Nexus 5 (5mb test):

HttpClientHandler:

AVG:
Read: 5792 bytes

PEAK:
Read: 40544 bytes


AndroidClientHandler:

AVG:
Read: 8192 bytes

PEAK:
Read: 43164 bytes

The only problem here is that I see too much variance. For example:

HttpClientHandler

1st Run - 6s
2nd Run - 3s
3rd Run - 5s

AndroidClientHandler

1st Run - 4s
2nd Run - 7s
3rd Run - 5s

Thus I cannot see a major difference in a small download. However in a larger download(as noted above) and if I had more time testing, I believe I would see a major difference in byte read size over a long period. I believe this test case might benefit from capturing each byte read and calculating the average, peak, and other items. This would also save time reading logs to have more conclusive evidence. However I will have to revisit this another day. Perhaps our engineering team can chime in on this issue. I'll go ahead and ask somebody to look into this. Thanks again!
Comment 4 Marek Habersack 2017-08-09 10:57:38 UTC
I was able to reproduce the 8k limit result from the OP, on a Nexus 9 running Android 7.1.1 even with a number of modifications I made to our code. Unfortunately, it seems at this point that this is something we have no influence on - especially considering results posted by Jon in comment 3. This is the same code Rupert and I used to reproduce the OP results, which suggests that the cause lies in the underlying Java code and might be specific to the Android OS version.
I'll investigate a few more possible tweaks but I'm not hopeful we'll find a solution.