calcul de débit réseau

Le
Nicolas-Michel_REMOVE
Bonjour

Je voudrais voir quel débit j'ai en lecture sur un serveur.
Ceci en faisant abstraction de ce qui s'y connecte.
Mais en incluant l'accès disque, le serveur lui-même, la connextion
réseau et si possible le protocole.


J'ai tenté ceci :

time scp -qr folder_source autreServer.ici.ch:/dev/null/

Mais ça me dit :
scp: /dev/null/: Not a directory

Alors j'ai fait ça :
find source -type f -exec cat {} ; | ssh -l user server.ici.ch "dd
of=/dev/null" ; date

Qui semble fonctionner.

Mais ça prends pas en compte le protocole.
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, )


Merci d'avance :)


--
Nicolas Michel
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #6781411
À (at) Thu, 5 Jun 2008 11:32:55 +0200,
(Michel Nicolas Alex) écrivait (wrote):
J'ai tenté ceci :

time scp -qr folder_source autreServer.ici.ch:/dev/null/

Mais ça me dit :
scp: /dev/null/: Not a directory


/dev/null est un fichier (donc pas de / à la fin) :

time scp -qr folder_source autreServer.ici.ch:/dev/null

Mais ça prends pas en compte le protocole.
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, ...)


Le débit du réseau ? Ou le débit perçu par l'utilisateur ?

--
Paul Gaborit -
Nicolas-Michel_REMOVE
Le #6781721
Paul Gaborit
À (at) Thu, 5 Jun 2008 11:32:55 +0200,
(Michel Nicolas Alex) écrivait (wrote):
J'ai tenté ceci :

time scp -qr folder_source autreServer.ici.ch:/dev/null/

Mais ça me dit :
scp: /dev/null/: Not a directory


/dev/null est un fichier (donc pas de / à la fin) :

time scp -qr folder_source autreServer.ici.ch:/dev/null


en fait j'ai testé les deux.

scp -qr source :/dev/null
Password:
scp: /dev/null: Not a directory

Et à part ça, c'est pas un socket /dev/null ?
Un socket est-il un fichier ?

Mais ça prends pas en compte le protocole.
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, ...)


Le débit du réseau ? Ou le débit perçu par l'utilisateur ?


je ne sais pas ce que tu veux dire par "perçu par l'utilisateur".

Je veux juste pouvoir faire des tests concrêt sur des serveur de
fichiers :

De combien le protocole modifie la performance ?
Quelle différence _finale_ entre un san fiberchannel et multilane sata ?
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce
ne soit plus la connection 100baseT du client qui le limite ?
Quelle sera la fenêtre de backup ?

Un collègue me dit que selon ses logs il a un débit qui varie entre 10
et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de
la chaine de ses serveurs n'est aussi faible : disques raid, connection
fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais
comprendre. Pour ça il me faut un moyen d'analyse.

Merci :)
--
Nicolas Michel


Eric Levenez
Le #6781711
Le 05/06/08 12:29, dans
Nicolas Alex »
scp -qr source :/dev/null
Password:
scp: /dev/null: Not a directory


Scp essaye de créer des fichiers et répertoires dans /dev/null (car copie
récursive). Cela ne peut pas marcher.

Et à part ça, c'est pas un socket /dev/null ?


Non., c'est un fichier spécial caractère.

Un socket est-il un fichier ?


Tout (ou presque) est fichier sur Unix. Le socket peut être un fichier,
comme /dev/null est un fichier ou comme un répertoire est un fichier. Mais
il y a plein de types de fichiers et les fichier "normaux", ne sont qu'un
type parmi d'autres.

Mais ça prends pas en compte le protocole.
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, ...)


Le débit du réseau ? Ou le débit perçu par l'utilisateur ?


je ne sais pas ce que tu veux dire par "perçu par l'utilisateur".

Je veux juste pouvoir faire des tests concrêt sur des serveur de
fichiers :


C'est donc du utile applicatif, pas du débit brute.

De combien le protocole modifie la performance ?


Cela dépend fortement du protocole.

Un collègue me dit que selon ses logs il a un débit qui varie entre 10
et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de
la chaine de ses serveurs n'est aussi faible : disques raid, connection
fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais
comprendre. Pour ça il me faut un moyen d'analyse.


Tout cela dépend aussi de ce que l'on sauvegarde et comment. Un gros fichier
de 1 Go ira plus vite sur une connexion qu'une multitude de fichiers de la
même taille globale.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.



fx [François-Xavier Peretmere]
Le #6782081
on the 5/06/08 12:29 Michel Nicolas Alex wrote the following:
...
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, ...)
Le débit du réseau ? Ou le débit perçu par l'utilisateur ?



je ne sais pas ce que tu veux dire par "perçu par l'utilisateur".

Je veux juste pouvoir faire des tests concrêt sur des serveur de
fichiers :

De combien le protocole modifie la performance ?
Quelle différence _finale_ entre un san fiberchannel et multilane sata ?
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce
ne soit plus la connection 100baseT du client qui le limite ?
Quelle sera la fenêtre de backup ?


En général c'est plutôt l'applicatif qui dicte la fenêtre de sauvegarde, et
on aligne ensuite l'infrastructure dessus. :)

Un collègue me dit que selon ses logs il a un débit qui varie entre 10
et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de
la chaine de ses serveurs n'est aussi faible : disques raid, connection
fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais
comprendre. Pour ça il me faut un moyen d'analyse.


Cela ne sera pas aussi simple; le logiciel, le type de sauvegarde, la nature
des données sauvegardées, la configuration du stockage, la configuration des
machines ont aussi leur importance. On peut procéder par couche, sachant que
la vitese maximale sera celle du lien le plus lent. Mais c'est rarement
super simple et il vaut mieux bien connaître les détails des différents
éléments.

Fx

--
"Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering
their time inventing and implementing new, exciting ways for software
to suck." -- Toni L. in alt.sysadmin.recovery



Anonyme
Le #6783031
Michel Nicolas Alex
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce
ne soit plus la connection 100baseT du client qui le limite ?
Quelle sera la fenêtre de backup ?

Un collègue me dit que selon ses logs il a un débit qui varie entre 10
et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de
la chaine de ses serveurs n'est aussi faible : disques raid, connection
fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais
comprendre. Pour ça il me faut un moyen d'analyse.


Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.

--
Anonyme ( jayce <@> mosx.org )
********* MosX.org (MosX.net renaît sous le nom MosX.org...)

patpro ~ Patrick Proniewski
Le #6783011
In article (Anonyme) wrote:

Michel Nicolas Alex
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce
ne soit plus la connection 100baseT du client qui le limite ?
Quelle sera la fenêtre de backup ?

Un collègue me dit que selon ses logs il a un débit qui varie entre 10
et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de
la chaine de ses serveurs n'est aussi faible : disques raid, connection
fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais
comprendre. Pour ça il me faut un moyen d'analyse.


Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.


oui, et puis c'est théorique, on ne les atteint jamais.
En facteur limitants, en dehors du protocole réseau utilisé (ce qui
semble t'inquiéter à mon avis inutilement), tu vas avoir :

- la qualité du driver réseau sur chaque système
- la config du firewall du client, et du serveur (on a vu des cas ou le
débit est moisi sous Mac OS X avec certains réglages de firewall/nat)
- la taille des fichiers
- leur emplacement sur le disque, et leur destination sur le disque du
serveur
- débit et temps d'accès des disques client et serveur

Si tu veux vraiment avoir une idée précise de tout ça, il faudra faire
un test grandeur nature : backuper 2 ou 3 machines en utilisant des
protocoles différents, et en plaçant un soft de monitoring entre le
serveur et les clients (style wireshark).
Tu lances ça la nuit, et le lendemain, tu analyses.

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133


Paul Gaborit
Le #6783001
À (at) Thu, 5 Jun 2008 12:29:29 +0200,
(Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit
/dev/null est un fichier (donc pas de / à la fin) :

time scp -qr folder_source autreServer.ici.ch:/dev/null


en fait j'ai testé les deux.

scp -qr source :/dev/null
Password:
scp: /dev/null: Not a directory

Et à part ça, c'est pas un socket /dev/null ?
Un socket est-il un fichier ?


/dev/null est un fichier "spécial" (un puit sans fond)...

Je n'avais pas vu le 'folder_source'. On peut évidemment pas recopier
un répertoire vers un simple fichier.

Pour vos tests, utilisez plutôt un gros fichier :

time scp -q gros_fichier autreServer.ici.ch:/dev/null

et là, ça marchera.

--
Paul Gaborit -

Nicolas-Michel_REMOVE
Le #6783441
Paul Gaborit
Pour vos tests, utilisez plutôt un gros fichier :

time scp -q gros_fichier autreServer.ici.ch:/dev/null

et là, ça marchera.


Sauf que ça ne sera pas réaliste.

Dans la vraie vie on a pas qu'un seul gros fichier.
Et ça change tout.
(dans un de mes tests je mettais 30 minutes un dossier de zero kb
contenant 10'000 fichiers vides

--
Nicolas Michel

patpro ~ Patrick Proniewski
Le #6783431
In article
(Michel Nicolas Alex) wrote:

Paul Gaborit
Pour vos tests, utilisez plutôt un gros fichier :

time scp -q gros_fichier autreServer.ici.ch:/dev/null

et là, ça marchera.


Sauf que ça ne sera pas réaliste.

Dans la vraie vie on a pas qu'un seul gros fichier.
Et ça change tout.
(dans un de mes tests je mettais 30 minutes un dossier de zero kb
contenant 10'000 fichiers vides


ce qui est aussi un test hyper-réaliste :)

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133


Paul Gaborit
Le #6783891
À (at) Thu, 5 Jun 2008 16:45:16 +0200,
(Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit
Pour vos tests, utilisez plutôt un gros fichier :

time scp -q gros_fichier autreServer.ici.ch:/dev/null

et là, ça marchera.


Sauf que ça ne sera pas réaliste.

Dans la vraie vie on a pas qu'un seul gros fichier.
Et ça change tout.
(dans un de mes tests je mettais 30 minutes un dossier de zero kb
contenant 10'000 fichiers vides


Un dossier contenant 10000 fichiers (même vides) ne pèse pas 0Ko !
D'ailleurs un fichier de 0Ko n'occupe pas 0Ko sur le disque. Il occupe
au minimum le nombre d'octets nécessaires au stockage de son nom !

Et ce test n'est pas plus "réaliste" que celui que je proposais.

Le seul test "réaliste" est la mesure de l'activité réelle. Et cette
mesure peut changer selon les conditions.

--
Paul Gaborit -

Publicité
Poster une réponse
Anonyme