# [Download][Débat] Télécharger plus vite en ligne de commande

## gbetous

Bonjour !

Pour télécharger en ligne de commande, j'utilise curl ou wget. Seulement il me semble une fois avoir utilisé un truc avec un nom du style accel, qui balançait plusieurs threads de téléchargement... J'arrive plus à le retrouver.

Qqu'un connait ?

----------

## cylgalad

Non et il parait que ça n'est pas bien de lancer plusieurs "threads" pour un fichier...  :Wink: 

----------

## Uggy

Axel - A light download accelerator for Linux.

----------

## cuicui

```
lftp -c "pget http://..."
```

----------

## kernelsensei

Moi j'utilise aria2c qui permet de télécharger un fichier de plusieurs sources en même temps.

----------

## gbetous

c'est axel que je cherchais, mais merci aux autres, je vais regarder tout ça !

----------

## Ey

 *cylgalad wrote:*   

> Non et il parait que ça n'est pas bien de lancer plusieurs "threads" pour un fichier... 

 

Oui c'est meme *TRES* mal. Plusieurs threads ca signifie des acces concurent sur le meme fichier sur des plages non continues, bref si tout le monde fait ce genre de conneries :

- il ne peut pas y avoir de gain de vitesse vu que de toute facon les ressources du serveur ne vont pas augmenter...

- en fait ca fait meme perdre ennormement en terme de performances parce que les temps d'acces sont enorme par rapport aux autres facteurs permettant de calculer le debit

- et pour finir en plus ca fatigue inutillement les disques.

Bref c'est un peu comme le dilleme du prisonnier... sauf qu'en plus il y a un facteur usure qui fait chier le proprio du serveur.

----------

## ghoti

 *Ey wrote:*   

> Plusieurs threads ca signifie des acces concurent sur le meme fichier sur des plages non continues, bref si tout le monde fait ce genre de conneries

 

Mais tout le monde fait ce genre de connerie et même sans le savoir : 10 clampins qui déchargent le même fichier, ça revient au même qu'un seul gaillard qui utilise 10 threads. Non ?

Au total, il y a 10 connexions qui font les mêmes "dégats". Un serveur convenable est construit pour répondre à ce genre d'exigence.

Par contre, là où je pourrais te rejoindre, c'est que cette manière de procéder se fait au détriment des autres utilisateurs, lorsqu'il s'agit de serveurs faiblards. Et ça, c'est peut-être plus discutable que des questions de quincaillerie...  :Wink: 

----------

## gbetous

ah ? c'est pas recommandé ? vu que c'est une possibilité offerte par le serveur, je pensais que ça posait pas de pb en fait..

----------

## Ey

 *ghoti wrote:*   

> Mais tout le monde fait ce genre de connerie et même sans le savoir : 10 clampins qui déchargent le même fichier, ça revient au même qu'un seul gaillard qui utilise 10 threads. Non ?

 

Oui ca fait 10 acces concurents, c'est pas la mort, maintenant si les dix boulets mettent 10 threads on est a 100 acces concurent et CA c'est n'importe quoi et franchement neffaste meme pour les 10 boulets en question.

 *Quote:*   

> Au total, il y a 10 connexions qui font les mêmes "dégats". Un serveur convenable est construit pour répondre à ce genre d'exigence.

 

Le serveur peut répondre à la demande là n'est pas la question. Le problème c'est que le résultat est totalement sous-optimal et neffaste pour l'espérance de vie des disques.

 *Quote:*   

> Par contre, là où je pourrais te rejoindre, c'est que cette manière de procéder se fait au détriment des autres utilisateurs, lorsqu'il s'agit de serveurs faiblards. Et ça, c'est peut-être plus discutable que des questions de quincaillerie... 

 

Non ca se fait au détriment des autres utilisateurs quoi qu'il arrive. Bref si tout le monde fait pareil cette méthode ne peut pas fournir plus de bande passante, et meme pire, vu qu'elle augmente nettement le nombre d'acces concurent elle reduit en fait les performances globale du serveur. Bref c'est completement egoiste et inefficace comme facon de procéder.

----------

## nonas

Néanmoins pour des cas précis, Axel a l'air super intéressant : le coup de télécharger un bout du fichier sur chaque miroir, c'est pas mal je trouve.

Après, sauf fichiers ultravolumineux et vu les lignes qu'on a, je préfère aller boire un café en attendant que le fichier soit là  :Wink: 

Pour d'autres cas, faut se dire que si la bande passante est limitée c'est rarement pour faire chier l'utilisateur (et pour le cas du ftp, si l'admin s'embête à mettre un quota de bp par connexion mais pas de quota de connexion par ip, ben c'est pas un bon admin   :Laughing:  ), donc si c'est parce que le serveur est déjà faiblard (vive les serveurs à la maison avec peu d'upload...), au mieux ça ira pas des masses plus vite, au pire le fichier en question sera viré car trop consommateur.

Laissons du temps au temps (ouh c'est choli !)

----------

## gbetous

En fait quand j'utilise plusieurs threads (4 est un chiffre max), c'est plutot pour lisser la bp que pour passer outre des mesures de limitations !!!

En effet, avec 4 threads, j'arrive quasi systématiquement à maintenir le débit max de ma ligne (1024/256, c'est pas le bout du monde quand meme), contrairement à un seul thread, ou en général je suis entre 5% et 10% en dessous.

----------

## cylgalad

Forcement, tout le monde fait comme toi, il faut donc 4 fois plus de ressources...

En fait je "sature" mes 4 Mb avec emerge qui utilise wget...

----------

## avendesora

 *gbetous wrote:*   

> contrairement à un seul thread, ou en général je suis entre 5% et 10% en dessous.

 

Peut-être j'ai mal compris, mais si tu es à 100% avec 4 threads, et 90-95% avec juste un, est-ce que peut-être

ces 5-10% "gagnés" ne seraient pas en fait en très grande partie

- les packets qui te servent à maintenir 3 cnx tcp en plus

- les retry/timeout tcp et autres générés parce que justement tu statures ton lien

(et donc tu gagnes quelques bits par seconde en plus en faisant chauffer plus ton pc, le serveur sur lequel tu

pompes, et tous les routeurs au milieu).

Pas très "écolo".

----------

## gbetous

Pas la peine de me pourrir   :Crying or Very sad:  , j'en savais rien moi !

1) C'est un service que permet le serveur, donc pourquoi ne pas s'en servir ?

2) Oui, il n'y a que 5 ou 10% d'écart, mais encore une fois, comme je pensais pas que derrière ça pouvait mettre à plat un serveur, pourquoi s'en passer ?

3) C'est bon, j'ai compris, c'est mal, je n'utiliserai plus de threads...

----------

## avendesora

 *gbetous wrote:*   

> Pas la peine de me pourrir   , j'en savais rien moi !

 

Ou là, c'était pas pour te pourrir du tout, juste pour amener quelques points de réflexion au débat  :Smile: 

 *Quote:*   

> C'est un service que permet le serveur, donc pourquoi ne pas s'en servir ? 

 

Ouais, pas souvent un bon argument - ma voiture me permet aussi de jouer au bowling avec les piétons...   :Twisted Evil: 

ok, ok je sors   :Arrow: 

----------

## guitoo

C'est un peu comme prendre 2 plats au self.

----------

## gbetous

 *Quote:*   

> Ouais, pas souvent un bon argument - ma voiture me permet aussi de jouer au bowling avec les piétons...  

 

Non, je le répète, c'est le SERVEUR qui l'autorise, pas le client (qui serait la voiture dans ton analogie). Comprenez que c'est dur d'imaginer qu'il autorise qqchose qui le pénalise !!!

----------

## gbetous

 *guitoo wrote:*   

> C'est un peu comme prendre 2 plats au self.

 

Si je demande "bonjour, est-ce que je peux prendre 2 plats", et qu'on me répond "oui"... bin j'en prends 2. c'est pareil avec les threads. Suffit de dire non.

----------

## Oupsman

 *Ey wrote:*   

> 
> 
> Oui ca fait 10 acces concurents, c'est pas la mort, maintenant si les dix boulets mettent 10 threads on est a 100 acces concurent et CA c'est n'importe quoi et franchement neffaste meme pour les 10 boulets en question.
> 
> 

 

T'oublies juste un détail dans ton argumentation : le cache en RAM

EDIT : et le cache propre aux disques voire à la carte RAID dans le cas d'un serveur de bonne qualité

----------

## cylgalad

 *gbetous wrote:*   

> 
> 
> 1) C'est un service que permet le serveur, donc pourquoi ne pas s'en servir ?
> 
> 

 

Non, ça n'est pas un "service", c'est juste que les serveurs http doivent être accessibles pour plusieurs pages web par client : pas pour des fichiers de 4 Go, pas pour faire l'apologie de logiciels à la con comme flashget & cie qui ont inventé un argument purement marketting ou tout du moins lié au fait que les serveurs II$ sont super-lents (ce qui ne s'arrange pas avec le multithread). Il s'agit donc bien d'un abus, pas d'un service.

D'ailleurs de plus en plus de serveurs sont configurés pour envoyer les gros fichiers qu'à une connexion par IP.

----------

## gbetous

 *cylgalad wrote:*   

> 
> 
> Non, ça n'est pas un "service", c'est juste que les serveurs http doivent être accessibles pour plusieurs pages web par client

 

Ahhh.... j'avais pas compris ça du tout... Bon, si tu le dis...

----------

## Ey

 *Oupsman wrote:*   

> T'oublies juste un détail dans ton argumentation : le cache en RAM
> 
> EDIT : et le cache propre aux disques voire à la carte RAID dans le cas d'un serveur de bonne qualité

 

En fait le cache du controleur RAID tout comme la RAM permet surtout de limiter les degats lors d'acces a beaucoup de petits fichiers, mais quand on est dans le cas présent - récupérer un très gros fichier (parce que pour récupérer 10k franchement 10 threads ca fait plus d'échanges de SYN que de vrai paquet DATA) - le cache ne joue que très peu car quel que soit sa taille il est largement sous dimensionné par rapport aux fichier récupéré. Bref le cache du controleur RAID ne joue que pour limiter les conséquence d'acces trop nombreux (lecture de blocs trops petits) effectués par l'OS. 

La RAM elle n'apporte presque rien pour de gros fichiers (pour de petits fichiers elle peut éventuellement servir a éviter d'aller le lire 10 fois pour 10 utilisateurs différents), mais pour un fichier de plusieurs dixaines de megs si tu es sur un vrai serveur qui partage plus d'un fichier c'est completement dérisoire de s'imaginer qu'il puisse conserver un nombre suffisament important de fichiers en RAM pour qu'un nombre significatif de client tombent sur des fichier en cache.

Bref le cas pour moi ou la RAM joue le plus c'est dans le cas ou le multi-thread sur un même fichier n'apporte vraiment rien meme en supposant que les autres eux n'ont pas cette brillante idée.

Pour répondre à la question : "mais pourquoi c'est permis si c'est mal", la réponse est simple : les client en question détournent deux fonctionnalités d'un protocole (souvent HTTP) :

- la possibilité (confort utilisateur) de pouvoir résumer un téléchargement sans avoir à tout reprendre au début. => il lance des résume à plusieurs endroit du fichier pour pouvoir récupérer les bouts

- la possibilité d'ouvrir plusieurs connexions sur le même serveur (les clients fonctionnant avec la version 1.0 du protocole HTTP par exemple ouvrent en fait une connexion pour chaque élément de ta page : la page HTML elle même, mais aussi chaque image / frame / ...).

Bon après j'ai toujours tendance à avoir des avis assez tranchés sur les choses hein, il faut pas non plus prendre mes remarques trop à coeur, mais il me semblait important d'apporter un regard critique sur cette pratique.

----------

## Ey

 *Ey wrote:*   

> Bref le cache du controleur RAID ne joue que pour limiter les conséquence d'acces trop nombreux (lecture de blocs trops petits) effectués par l'OS. 

 

Ah oui une petite remarque avant que les gens s'enflamment : je parlais de ce qui se passe lors de la lecture hein, n'allez pas non plus me faire dire que ca ne sert a rien du tout.

PS : oui bon histoire de terminer et d'éviter d'éventuelles questions telle que "à quoi ça sert en écriture ?" : ça sert à permettre à l'OS de donner un fichier à écrire à la carte et arrêter de s'emmerder avec ca, le fichier est dans la RAM du controleur le temps d'aller l'écrire, alors oui ça peut prendre plusieurs secondes mais l'OS lui il s'en fout il a fait son boulot, le reste c'est plus son problème. En lecture on peut difficilement fonctionner de la même façon : soit on a de la chance et les données sont déjà en cache (hypothèse probable si on à un nombre limités de fichiers très souvent accédés), soit il faut forcément attendre que le disque retourne les données avant de pouvoir s'en servir.

----------

