and if having it singlethreaded would not actually be better perf wise

It will be most probably much better if your server is fast enough, because IO is bottleneck in most cases

Not sure if I understand. Are you saying singlethreaded queue will be better because the parallel downloads will compete for bandwidth?

No, I do not suggest singlethreaded queue

and by IO you mean reading writing the socket?

Yes, bandwidth may be a bottleneck, there is no simple answer, but in general most probably running multiple IO events in parallel would be better than do that one by one,

naively, do you think they would run at same speed per download (parallel vs single) ?

It really depends on network and server

I know, but in general, for some average apache or something like that, i.e. if parallel downloads could noticably downgrade the speed is what am getting at

In general better to do that in parallel I believe, if your target goal is “download all files” If your use case “make any file available as soon as possible” than download sequentially is probably better strategy

well, that depends on the overhead, since in sequential you wait in queue, which i supposed will be way longer than download time in parallel + overhead?

as I said, it depends on your use case. Do you want download everything as fast as possible? than do it in parallel, with some reasonable limitations (not more than n downloads in paralle). If your goal to provide access to some of files even before all of them are downloaded, than use sequntail downloading or even more limited paralle

Ok ok, yes, the use case is mix of both, its downloading of files in messenger, i.e. you click download on a download message

For messenger use case I would download sequentially or with small parallelism, no need to download everything, user see only last few files at the same time

Ok thanks I was just wondering if for n large downloads, the speed would drop to 1/n or something, since if there is not some fixed total IO ammount per OS or something

It really depends on many factors

yes sure, n is low like idk .. 10 maybe

do this in perfectly optimzied way is very tricky, so better to choose some “good enough strategy for most cases”

so batches of say 5 in parallel sounds reasonable for generic messenger ui user driven use case

if you want to sync everyhing yes, but I’m not sure that it’s the best strategy for messanger

Not really syncing, im thinking about like in slack youd post a file and the other user clicks on it to download it locally

so it by request? if so just do this sequentially or with small parallelist, like 3-5

yes by user request, not automatically (although there will be some automatics when restarting the app and it recognizes some downloads didnt finish downloading)

User story

im confused now 😄 so there is a time penalty to such paralelism per downlaod vs singlethreaded?

No, it’s about user story

yes, and they all start downloading, each on its own thread

I would like probably open at least one of them as fast as possible

and if each download eats like 5% penalty for paralelism, then thats fine, as opossed to waiting in queue for the 10th, no?

It’s not about penalty

should be way faster, and first will be only 5% slower

As a user I would like to get my first file faster even if overal download speed was slower, do you see what I mean?

true, but 5% is negligable .. 20-30 would be not

but because in most cases bandwidth is bottleneck, you will get bigger difference

im not sure if I understand where its the bottleneck, do you mean like phone's total bandwidth?

so in perfect condition if you have exactly 1mb per second, to download 2 1mb files you need 2 seconds

im a total noob to this, but naively im thinking if the pipe is wide lets say 1MB/s

yes

okay I see, so the total speed is constant and paralelism just gets fractions

for simple case it work like that

okay now I understand what you meant by when you want your first file

but on practice parallel download usually faster, because you also pay local IO, file processing, connection timeout, problems with particual files download speed etc

since in theory the last file will download in exactly the same time

so usually parallel download result is better

you mean faster to downlaod all the files, but speed per file is still going to be 1/n?

chrome has pretty different use case

not really, you click 3 different download links, you download 3 files in parallel, those 2 dont wait in queue

chrome usually download files from multiple websites and on your home wifi, when your local bandwidth is usually wider than remote web service

yea, does that make a difference if its a different tcp connection, different socket?

sure

hm, but isnt it the same for 1 phone to have 5 downloads / connections, vs 5 phones having single connection -- in server's eyes?

no, because download 5 files is more efficient than one by one

that is what im saying, i mean a regular server can handle hundreds of parallel connections for sure, right?

Yes

so by that logic id expect it to be same thing in terms of backend, if it is single client making hundreds of connections vs hundreds of clients making single connection?

there is no difference

hm, true

Yes, but if web server doesn’t support resume of upload probably safer would do this sequentially

how so? I mean sure, but resuming can be also done on downloads

In 99% cases nobody support resuming of download or upload