Discussion :

[Frich]

Pour changer de mes problemes de SGBD etant actuellement en stage mon maitre de stage me demande de réaliser un bench TCP en Perl via serveur Apache (je sais ke là ca n'as rien de clair...)

donc le truc c un script perl via serveur apache va télécharger un fichier sur une machine précise, fichier d'une taille connue et ensuite générera une page web montrant le débit de cette transaction, en clair.. une fichier sera téléchargé d'une machine voulus vers le serveur apache via un script perl

script perl lancé par un client via l'inteface web et aura une joli page avec la durée du transfert, la taille du paquet et enfin le débit utile!!

mon probleme est dans la façon de faire ca!! mon maitre de stage pense à faire un net use pour télécharger un fichier d'une taille de 100mo et voir le temps que ca met, et ensuite voir une autre methode pour les machines linux!!

si qq'un aurais une idée un peu moins violente et ne necessitant pas de savoir l'os de la machine distante...

moi je penserais bien à une connexion tcp (obligeant à avoir un demon qui tourne sur chaques machines que l'ont veut bencher) (ces machines sont des serveurs)
mais celà permetterais de ne pas utiliser de fichier qui prennent de la place, et de pouvoir gérer la quantitée de donnée à envoyer


j'attend vos avis, et si g pas été tres clair et bien... poser moi des questions!!

[Frich]

je vais poser ma question autrement, car le probleme n'est pas dans le code, mais dans le principe

vaut-t-il mieux pour le bench :

transférer un fichier d'une machine à l'autre (fichier d'une taille connue) ainsi par la meme ocasion on bench les autres piles de la machine et pas seulement TCP (methode proposée par mon maitre de stage) posant tout de meme un probleme, sous windows cela nécessite une utilisation de net use et sous linux des partages NFS cad savoir l'os de la machine à bencher!!

transférer par un demon TCP (coder en C ou C++) un grand nombre d'octet pour avoir la meme information de bench, donc plus besoin de savoir l'os de la machine (suffit de compiler le prog sur la bonne machine et de l'executer) par contre on ne bench que le TCP et pas les autres piles de la machine

j'espere que vous me répondrez assez rapidement, merci d'avance

[BlackEagle]

vas sur NetIQ
tu download QCheck

c'est un ti programme qui teste les performances entre 2 machines
tu peux tester le ping tcp et ping udp ainsi que le streaming
(c'est pratique quand tu veux mettre de la voix sur IP pour voir les pertes)

mais sinon c un bon produit gratuit !
le seul pb c que chui pas sûr que ça t'aide !! surtout si c toi qui doit faire le programme en perl !

[Frich]

en fait oué je v réaliser mon propre bench!!
le pb n'est pas de la programmation ca je m'en sort à peu pres, c de la méthode à utiliser
(faut que je génere une page oueb pour les stats et donc c la facon dont va agir le script perl qui m'intéresse)

g commencé à codé les partie à bencher (pour le moment windows linux viendra plus tard) et je découvre de plus en plus que ché win ils aiment nous simplifier la vie en C pas de socket mais winsock, pas de fork mais utilisation de thread (ke g pas encore completement compris)

bon, c ou k'on achette un couteau rouillé pour embroché billou, et une corde pour.... moi

je m'en va retourner à coder

windozzzzzz qd tu nous tien

[Frich]

avancement de ce petit développement

alors voila g pus réaliser avec mon collegue un bench assez simple

le client demande une connexion avec mot de passe (une chtite securité)

plus une taille d'octet à envoyer

le serveur (linux ou windows,il fé les 2) renvois les octets demandé en utilisant le max de la bande passante

une fois celà fait, le client fait un petit calcul sur le débit!!

c joli ms maintenant, en imaginant qu'on fasse ce bench assez régulierement, qu'on stock les valeurs obtenues dans une base ou dans un fichier (surement une base)

le but serai par une page web de pouvoir récupérer un graphique, d'ou une petite demande
comment faire via un script PERL ou PHP (rien ne me fé peur ) une methode pour créer ce graphique (debit selon le temps) afin de voir les baisse de performance au nivo du reseaux

@ bientot