É uma boa ideia fazer upload de vários arquivos em paralelo?

Estou desenvolvendo um aplicativo para fazer upload de vários arquivos grandes para um servidor de uma rede doméstica.

Eu posso selecionar qualquer uma das seguintes estratégias:

Carregue cada arquivo em sequência.
Faça o upload de todos eles em paralelo.

qual é mais rápido, observando que o gargalo é a rede doméstica.

networking internet broadband

— mans
fonte

Experimente os dois e meça os resultados?

— multithr3at3d

@ multithr3at3d Meu teste seria de uma posição, e estou procurando conhecer o conceito geral que seria válido em todos os lugares.

— Mans

@man - "em todos os lugares" é extremamente amplo. Além disso, você subestima a validade de uma referência como essa. O que se aplica à sua conexão, basicamente se aplica a todos, de qualquer maneira

— Ramhound

Edite a pergunta para limitá-la a um problema específico com detalhes suficientes para identificar uma resposta adequada.

— Ramhound

Você está fazendo o upload para "um servidor". O que você sabe sobre o servidor? Existe alguma possibilidade de que é realmente um farm de servidores, onde as conexões paralelas estão realmente indo para endereços IP diferentes?

— Scott

Respostas:

-1

No seu caso, o upload em sequência pode ser necessário.

O hardware do consumidor nem sempre é capaz de executar muitas conexões simultâneas e pode parar / travar. Se você limitar a quantidade de arquivos simultâneos, o upload paralelo sempre será mais rápido.

O motivo é o seguinte:

Quando você faz uma transferência usando TCP / IP, acontece o seguinte:

Primeiro um pacote é enviado para o destino, e a conexão espera que um pacote de confirmação retorne antes de enviar o próximo pacote.

Em seguida, envia 2 pacotes e aguarda a confirmação. Em seguida, ele envia 3, depois 4, depois 5, etc ... Ele continua aumentando a quantidade de pacotes até que o pacote de confirmação retornado mostre que nem todos os pacotes foram recebidos. Quando isso acontece, a velocidade é reduzida e tentada novamente.

Costumava ser que, quando isso acontecesse, começaria em 1 novamente e aumentaria a velocidade. A nova tecnologia reduz a quantidade de pacotes primeiro e tenta novamente, aumentando gradualmente a velocidade.

Dado que, com tráfego adicional, a largura de banda para essa transferência pode ser reduzida, é muito provável que a velocidade total não seja mantida o tempo todo.

Se 2 ou mais arquivos estiverem sendo transferidos ao mesmo tempo, a largura de banda disponível será utilizada com mais eficiência. Se uma única transferência travar e a velocidade for significativamente reduzida, haverá um momento em que a largura de banda será liberada e não será usada por essa transferência. Outros processos podem consumir essa largura de banda, tornando a transferência ainda mais lenta. Mas, se dois ou mais arquivos forem transferidos, é mais provável que a velocidade combinada seja mais ou menos mantida da mesma forma, o que significa que, mesmo que uma das transferências tenha diminuído, a outra transferência provavelmente terá essa largura de banda restante.

— LPChip
fonte

"Quando isso acontece, a velocidade é reduzida e tentada novamente ... aumentar a velocidade ... aumentando gradualmente a velocidade ... a velocidade é significativamente reduzida" - O que é essa "velocidade" a que você se refere? Seja tão técnico quanto você, eu posso lidar com isso.

— serragem

@sawdust Transferir velocidade. Uma transferência é feita por chunking everthing em pequenos lotes de pacotes. Vamos dizer em termos laymans, você tem largura de banda para exatamente 400 pacotes simultaneamente. Primeiro 1 pacote é enviado, portanto, há espaço para mais 399 pacotes, mas eles não são utilizados. Então 2, então 4 então 6 então 10 então 15 .. 400 de 400. Agora, um lote de 420 é tentado, mas a confirmação diz que os últimos 20 pacotes não chegaram. Por isso, repete esses 20 pacotes e limita a quantidade de pacotes a 210. Assim, a velocidade é reduzida quase pela metade porque poderia haver espaço para mais 190 pacotes.

— LPChip

Sua explicação não faz sentido. Ethernet IEEE 802.3 não tem a capacidade de transmitir "400 pacotes simultaneamente" . Não usa a largura de banda para transmitir quadros simultâneos. A velocidade do fio é fixada quando os PHYs negociam, mas você insinua que o TCP pode diminuir essa velocidade?

— serragem

Fazer o upload em paralelo geralmente ajudará a levá-los todos para lá mais rápido, porque se um de seus fluxos TCP de upload ficar parado por qualquer motivo, seus outros fluxos TCP de upload poderão evitar que essa largura de banda seja desperdiçada.

— Spiff
fonte

Basicamente a mesma resposta que a minha, mas mais compacta. : P

— LPChip

@LPChip "Basicamente a mesma resposta que a minha" - A primeira frase da sua resposta é o oposto da resposta. Então você acha que as respostas opostas são as mesmas?

— serragem

Teoricamente falando, a resposta seria:

Seis de um; meia dúzia de outro.

A razão é que, se você atingir um gargalo de largura de banda, não importa se você está enviando arquivos um de cada vez ou vários de uma só vez; você está limitado pela largura de banda.

O que altera a resposta é se existe um limite de velocidade imposto para conexões em um lado. Isso é visto em alguns servidores de conteúdo regulares, bem como aqueles que usam o protocolo Torrenting.

Nesse caso, se o limite de velocidade imposto for menor do que a largura de banda máxima no lado da residência, faria sentido transferir vários arquivos, até o valor para limitar a largura de banda no lado da residência.

— Damian T.
fonte