Bonjour Ploopie,
je viens de faire le test, je n'ai aucune différence notable, environ 1Gbps pour les deux situations, sur mon PC de bureau (bête de course core i7 récent avec une tonne de RAM).
Il faudrait détailler comment tu fais la chose, mais
surtout la puissance de ta machine !
Il est vrai qu'utiliser firefox pour donwloader un fichier "local" te fait passer par un certain nombres de couches supplémentaires !
En l'occurrence firefox va utiliser son driver "fichiers locaux", cela sera converti en "range" par le 1fichierfs qui va faire le curl.
De plus, passer par un driver fuse veut dire des aller/retour kernel/userland plus nombreux qu'un DL direct.
Donc cette différence de performance d'un facteur 5 ou 6 pourrait s'observer si tu as un machine vraiment très lente... je dirais du niveau d'un Raspberry Pi zéro !.. :lol:
Il faudrait donc que tu regardes la charge CPU de ta machine pendant que tu fais les 2 opérations.
Aussi il faut faire le test à la même heure, et pour éliminer les phénomènes de cache sur le serveur 1fichier, commencer par le télécharger une fois.
Sur mon PC (avec
top),
- En DL fichier local, firefox tourne à 65/70% CPU et 1fichierfs à 25/30%, on a un load average autour de 1.30
- En DL direct, firefox tourne à 95/110% CPU (et 1fichierfs n'est pas utilisé), on a un load average autour de 0.65
On voit que ça prend donc à peu près deux fois plus de charge d'empiler firefox par dessus le driver 1fichierfs, et en cas de machine limitée, ça peut faire la différence.
Sur mon PC de bureau, comme les CPU ne saturent pas à 100%, il n'y a pas de différence notable entre les deux façons de faire, c'est imperceptiblement plus lent avec le mode "fichier local" car firefox ne semble pas optimisé (il ne prend pas les 100% du CPU comme en mode direct).
Aussi, si c'est pour utiliser firefox l'intérêt est moindre... si tu utilises le driver, c'est pour t'en servir avec d'autres programmes, comme par exemple : VLC, kodi, ou simplement gérer tes sauvegardes.
Pour cela, je te recommande le test avec
pv
C'est un petit utilitaire génial qui te permet d'avoir une barre de progression dans des cas où tu n'en as pas, comme une copie de fichiers. pv transforme une lecture en stream, et il est donc idéal pour 1fichierfs.
Donc pour tester la vitesse tu fais :
(un coup de
sudo apt install pv
si tu ne l'as pas déjà)
$ pv ~/1fichier/fichier_de_test >/dev/null
8,03GiO 0:01:55 [71,4MiB/s] [====================================================================================================================================================================>] 100%
Avec pv sur le même test que tout à l'heure, on voit que 1fichierfs tourne autour de 60% de CPU et pv ne prend presque rien autour de 5%.
C'est donc plus "optimisé" qu'avec firefox.
Aussi, ce qui peut faire la différence est le SSL qui est sans doute différent entre firefox et les librairies utilisées par curl.
Tu peux faire le test sans SSL pour voir, il y a une option pour ça dans le driver, ou temporairement retirer SSL de ton cloud 1fichier.
Mais par exemple, sur mon Raspberry Pi 4, le même "pv" en SSL tourne autour de 14MBps, soit 6 fois moins vite que sur mon PC. Avec un top, on voit que 1fichierfs est à 100%, et avec les stats, on voit qu'on n'a un seul stream qui tourne (normal avec pv). Donc là c'est le CPU du Raspberry qui limite à cause de SSL.
Le test sur Raspberry Pi, sur la partie non SSL de mon stockage, donne aussi 1fichierfs à 100%, pv à 20% (plus que sur ma machine de bureau donc !) et on est pas loin des 1Gbps sans être aussi performant que sur un PC.
Donc le CPU y est pour quelque chose.
Pour comparer le comparable, avec un fichier identique en curl direct et via 1fichierfs, j'ai un performance 2 fois moindre avec 1fichierfs, mais dans les deux cas ça plafonne à 100% de CPU (avec SSL). La différence de performance est dues aux copies de buffer qu'on fait entre le kernel et le userland qui sont bien doublées avec fuse.
La seule façon pour accélérer, si la machine est multi-core, c'est d'utiliser des "accélérateurs de téléchargement" qui téléchargent des morceaux... mais dans tous les cas, à cause de fuse, le rapport performance/CPU est moins bon.
C'est la rançon de tout driver fuse hélas, et donc tu verras une différence de perf à partir du moment à ton CPU mouline à 100%... ce qui est donc dépendant de ta machine.
Du reste 1fichier a fait l'option "no SSL" pour ce genre de cas... le driver permet de ne pas utiliser SSL pour des parties distinctes de ton stockage. Personnellement j'ai désactivé SSL sur la partie de mes sauvegardes... puisqu'elle sont déjà chiffrées localement !
En conclusion, si ton usage est la performance, le moins de "couches" tu peux empiler, le mieux c'est !
La performance est déterminée par le "maillon faible". Chez moi, sur mon PC de bureau, c'est la fibre de Free à 1Gbps :lol:
Chez toi (et dans une moindre mesure sur mon Raspberry Pi), c'est le CPU qui limite (surtout en SSL).
Donc à toi de voir selon ton usage. Si tu as vraiment besoin de performance, un mode plus "direct" est recommandé. Si le côté "pratique" peut surpasser la perte de performance avec ta machine, alors tu peux utiliser le driver !
[Edit] cela dit, à l'occasion je tâcherai d'implémenter "read_buf" qui est sensé améliorer les choses car le kernel peut alors faire un "splice" ce qui allège le nombre de copies de buffers (ce qui prend le plus de temps).
