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, ...)
À (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 - <http://perso.enstimac.fr/~gaborit/>
Nicolas-Michel_REMOVE
Paul Gaborit wrote:
À (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
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Thu, 5 Jun 2008 11:32:55 +0200,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (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 admin@server.ici.ch:/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.
À (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 05/06/08 12:29, dans <1ii29mz.1y6zkjg107tc2kN%, « Michel Nicolas Alex » a écrit :
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 -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 05/06/08 12:29, dans
<1ii29mz.1y6zkjg107tc2kN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>, « Michel
Nicolas Alex » <Nicolas-Michel_REMOVE@THIS_bluewin.ch> a écrit :
scp -qr source admin@server.ici.ch:/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 -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 05/06/08 12:29, dans <1ii29mz.1y6zkjg107tc2kN%, « Michel Nicolas Alex » a écrit :
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 -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
fx [François-Xavier Peretmere]
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
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
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
Michel Nicolas Alex wrote:
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 <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
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 <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
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 <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
patpro ~ Patrick Proniewski
In article <1ii2edt.zyoyxq1esgiztN%, (Anonyme) wrote:
Michel Nicolas Alex wrote:
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
In article <1ii2edt.zyoyxq1esgiztN%jayce@mosx.org>,
jayce@mosx.org (Anonyme) wrote:
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
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
In article <1ii2edt.zyoyxq1esgiztN%, (Anonyme) wrote:
Michel Nicolas Alex wrote:
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
À (at) Thu, 5 Jun 2008 12:29:29 +0200, (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit wrote:
/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 - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 5 Jun 2008 12:29:29 +0200,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
/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 admin@server.ici.ch:/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 - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 5 Jun 2008 12:29:29 +0200, (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit wrote:
/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 - <http://perso.enstimac.fr/~gaborit/>
Nicolas-Michel_REMOVE
Paul Gaborit wrote:
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
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
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
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
In article <1ii2m9l.1thhuepv6wikrN%, (Michel Nicolas Alex) wrote:
Paul Gaborit wrote:
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
In article
<1ii2m9l.1thhuepv6wikrN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
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
In article <1ii2m9l.1thhuepv6wikrN%, (Michel Nicolas Alex) wrote:
Paul Gaborit wrote:
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
À (at) Thu, 5 Jun 2008 16:45:16 +0200, (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit wrote:
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 - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 5 Jun 2008 16:45:16 +0200,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
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 - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 5 Jun 2008 16:45:16 +0200, (Michel Nicolas Alex) écrivait (wrote):
Paul Gaborit wrote:
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 - <http://perso.enstimac.fr/~gaborit/>
