| View previous topic :: View next topic |
| Author |
Message |
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
 Posted: Sat Apr 07, 2007 8:57 am Post subject: [Download][Débat] Télécharger plus vite en ligne de comma |
 |
|
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 ?
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
Last edited by gbetous on Mon Apr 09, 2007 2:44 pm; edited 1 time in total |
|
| Back to top |
|
 |
cylgalad
Veteran
Joined: 18 Apr 2003
Posts: 1327
Location: France
|
| Posted: Sat Apr 07, 2007 10:06 am Post subject: |
|
|
Non et il parait que ça n'est pas bien de lancer plusieurs "threads" pour un fichier...  |
|
| Back to top |
|
|
Uggy
n00b
Joined: 27 Jan 2006
Posts: 56
|
| Posted: Sat Apr 07, 2007 10:09 am Post subject: |
|
|
| Axel - A light download accelerator for Linux. |
|
| Back to top |
|
|
cuicui
Apprentice
Joined: 17 Dec 2004
Posts: 208
|
| Posted: Sat Apr 07, 2007 12:52 pm Post subject: |
|
|
| Code: | | lftp -c "pget http://..." |
|
|
| Back to top |
|
|
kernelsensei
Bodhisattva
Joined: 22 Feb 2004
Posts: 5619
Location: Woustviller/Moselle/FRANCE (49.07°N;7.02°E)
|
| Posted: Sat Apr 07, 2007 6:06 pm Post subject: |
|
|
Moi j'utilise aria2c qui permet de télécharger un fichier de plusieurs sources en même temps.
_________________
$ ruby -e'puts " .:@BFegiklnorst".unpack("x4ax7aaX6ax5aX15ax4aax6aaX7ax2aX5aX8 \
axaX3ax8aX4ax6aX3aX6ax3ax3aX9ax4ax2aX9axaX6ax3aX2ax4ax3aX4aXaX12ax10aaX7a").join' |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Sun Apr 08, 2007 7:56 am Post subject: |
|
|
c'est axel que je cherchais, mais merci aux autres, je vais regarder tout ça !
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
Ey
l33t
Joined: 07 Apr 2005
Posts: 863
Location: Paris
|
| Posted: Sun Apr 08, 2007 5:30 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
ghoti
Advocate
Joined: 30 Dec 2002
Posts: 3634
Location: Belgium
|
| Posted: Sun Apr 08, 2007 6:18 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Sun Apr 08, 2007 7:37 pm Post subject: |
|
|
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..
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
Ey
l33t
Joined: 07 Apr 2005
Posts: 863
Location: Paris
|
| Posted: Sun Apr 08, 2007 8:34 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
nonas
Guru
Joined: 17 Apr 2005
Posts: 328
|
| Posted: Sun Apr 08, 2007 10:30 pm Post subject: |
|
|
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à
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  ), 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 !) |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Mon Apr 09, 2007 7:33 am Post subject: |
|
|
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.
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
cylgalad
Veteran
Joined: 18 Apr 2003
Posts: 1327
Location: France
|
| Posted: Mon Apr 09, 2007 9:31 am Post subject: |
|
|
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... |
|
| Back to top |
|
|
avendesora
Veteran
Joined: 16 Aug 2002
Posts: 1739
Location: Betelgeuse vicinity
|
| Posted: Mon Apr 09, 2007 10:17 am Post subject: |
|
|
| 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". |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Mon Apr 09, 2007 10:30 am Post subject: |
|
|
Pas la peine de me pourrir  , 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...
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
avendesora
Veteran
Joined: 16 Aug 2002
Posts: 1739
Location: Betelgeuse vicinity
|
| Posted: Mon Apr 09, 2007 10:55 am Post subject: |
|
|
| 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 
| 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... 
ok, ok je sors  |
|
| Back to top |
|
|
guitoo
Tux's lil' helper
Joined: 04 Jun 2004
Posts: 136
|
| Posted: Mon Apr 09, 2007 1:21 pm Post subject: |
|
|
| C'est un peu comme prendre 2 plats au self. |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Mon Apr 09, 2007 2:37 pm Post subject: |
|
|
| 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 !!!
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Mon Apr 09, 2007 2:38 pm Post subject: |
|
|
| 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.
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
Oupsman
Veteran
Joined: 19 Jul 2004
Posts: 1042
|
| Posted: Mon Apr 09, 2007 4:22 pm Post subject: |
|
|
| 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é
_________________
--
L'idéal de nouveauté semble avoir remplacé l'idéal de progrès. C'est bien triste.
----
Unix philosophy: "Do one thing and do it well."
systemd: "Try to do everything and do it wrong." |
|
| Back to top |
|
|
cylgalad
Veteran
Joined: 18 Apr 2003
Posts: 1327
Location: France
|
| Posted: Tue Apr 10, 2007 10:10 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Tue Apr 10, 2007 11:18 am Post subject: |
|
|
| 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...
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
Ey
l33t
Joined: 07 Apr 2005
Posts: 863
Location: Paris
|
| Posted: Tue Apr 10, 2007 6:45 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Ey
l33t
Joined: 07 Apr 2005
Posts: 863
Location: Paris
|
| Posted: Tue Apr 10, 2007 6:52 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
French
