I only recommend parallel for small transfers, where most of the
transfer time is spent on setup and tear-down (during which the
network
is mostly idle).

The problem with parallel on larger transfers is not so much CPU time
as
it is network congestion.  CPU usage is proportional to the total data
rate: it doesn't matter (much) if it gets split up across multiple
transactions.  But multiple parallel TCP streams can interact with
each
other in negative ways, particularly when bandwidth is scarce.  They
force latency higher (always a problem for TCP) and can force packet
loss higher (which can increase the incidence of failed connections).


Compression is a tricky business.  HTTP is nice because the server can
use MIME types to decide whether or not compressing a given object is
a
good idea.  So I agree that setting the HTTP compression headers is a
good idea, unless you know that you are transferring data that is
not-compressible (like pictures, audio, video, encrypted files, or
already compressed files).

The CPU overhead of compression becomes substantial enough to effect
transfer speed when the network is fast enough to saturate the CPU. In
the desktop world, this can begin to happen around 100 megabits per
second.  On gigabit networks, even compressible data may transfer
faster
without compression because of the CPU load.

Mobile is harder to predict because both the CPUs and the network are
slower.  I'd still recommend turning compression off if you know the
data is not compressible.

More thoughts on the pros and cons of compression can be found at the
link below, although it is definitely focused on the desktop world:

http://www.dataexpedition.com/support/notes/tn0014.html



On Mar 3, 6:10 pm, Miguel Morales <[email protected]> wrote:
> > Parallel transfers: Downloading two or three files at a time will
>
> usually help overcome the delay-between-files issue.  It increases
>
> the load at the server side, but that is usually only a problem when
>
> the total network speed exceeds 50 megabits per second.  So that
>
> shouldn't be an issue for mobile.
>
> Strange, I would think that paralell downloads would slow down the machine.
> I'd think you're saturating the 3g connection and  making your individual
> downloads much slower.
> This is why I implemented a network request queue for my app.  Now I'm
> wondering if I should have just left it.
> Handling failed downloads is a pain in the butt, to optimize that you could
> have some sort of 'resume' functionality.
>
> As for downloading HTTP content, I think you should always use compression.
> un/compressions is usually a fast function and the amount of time it takes
> to uncompress something is usually negligible.
> I would try to use the compression http headers and check if the server will
> serve the files using gzip encryption.
> This should definetly lower network transfer a bit.
>
> On Thu, Mar 3, 2011 at 12:40 PM, Maps.Huge.Info (Maps API Guru) <
>
>
>
>
>
> [email protected]> wrote:
> > My main app (Radar Now!) transfers one large (maybe 100kb) zip file to
> > the device from my server. Speed is less a problem then errors. Often,
> > it takes several attempts to get the file downloaded intact. I doubt
> > there's much that can be done about these errors as they are due to
> > spotty reception or overloaded networks rather than anything the
> > device itself is responsible for.
>
> > -John Coryat
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Android Discuss" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/android-discuss?hl=en.
>
> --
> ~ Jeremiah:9:23-24
> Android 2D MMORPG:http://solrpg.com/http://www.youtube.com/user/revoltingx

-- 
You received this message because you are subscribed to the Google Groups 
"Android Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-discuss?hl=en.

Reply via email to