IdentifiantMot de passe
Loading...
Mot de passe oubli� ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter

MFC Discussion :

[pipe nomm�s][multithreading]probleme de vitesse !!!?!


Sujet :

MFC

Vue hybride

Message pr�c�dent Message pr�c�dent   Message suivant Message suivant
  1. #1
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut [pipe nomm�s][multithreading]probleme de vitesse !!!?!
    Bonjour,

    Je suis depuis quelques temps confront� � un probleme et je n'arrive pas � mettre le doigt sur la source d'"erreur". J'ai d�velopp� recemment un serveur de communication et une biblioth�que cliente bas�e sur les pipes nomm�s windows. Le but �tant de communiquer en temps r�el entre les clients les valeurs de diff�rentes variables d�s leur changement.

    La probl�matique est que je n'obtiens pas les performances pr�vues...
    En effet le serveur ne r�ussi � transmettre qu'un message toutes les 30 ms (message et r�ponse de l'autre client). En regardant le gestionaire de taches, je peux remarquer que le processeur n'est absolument pas sollicit�.
    Le fait le plus troublant est que si je refais le m�me test avec une page web en flash ou un exe flash ouvert, les performances sont 10 � 12 fois sup�rieure!!!

    J'ai donc pens� pendant un moment � un ralentissement du � mes traces sur la console (ah oui, les clients et le serveur sont en mode console), en imaginant, que flash pouvait lancer une quelquonque acceleration materielle de l'affichage. Cependant, m�me en supprimant les traces, le probl�me persiste. Peut-�tre est-ce un probl�me d'ordonnacement? portaant il me semble que mes sections critiques sont prot�g�es au mieux et que les temps de suspension de thread sont minimums...

    A titre d'information, les clients ainsi que le serveur sont enti�rement d�velopp�s de mani�re parall�le:
    Le serveur poss�de 3 threads par client connect�s: un qui lit sur le pipe et empile les messages dans une file d'attente, un qui redirige les messages dans la file d'attente d'envoi de message du client destinataire et un qui d�pile les messages et les ecrit dans le pipe du destinataire. (architecture classique...)

    La biblioth�que poss�de 2 threads: un qui lit le pipe et empile les messages dans une liste de reception et un qui d�pile la liste d'envoi de message et �crit lesdits messages sur le pipe. (classique aussi)

    Si une personne a d�j� exp�riment� ce genre de probl�me, je suis tout ouie pour les conseils que vous pourriez me donner.

    visual'ment,
    Yverain.

  2. #2
    R�dacteur
    Avatar de farscape
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    Novembre 2003
    Messages
    9 055
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : High Tech - �diteur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 9 055
    Par d�faut
    salut,
    etonnant ,
    je pense qu'il faudrait que tu testes cette eventuelle lenteur dans un contexte simplifi� pour verifier si c'est le pipe nomm� qui rame ou si c'est l'implementation qui le ralentit....
    dans un post precedent j'avais post� ce code :
    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
     
    // server
    #include "iostream.h"
    #include <process.h>
    void msnpClientThread(HANDLE msnPipe)
    {
        char textBuffer[128];
        DWORD numBytesRead;
        DWORD numBytesWritten;
     
        while(1)
        {
            if(!ReadFile(msnPipe,textBuffer,128,&numBytesRead,(LPOVERLAPPED)NULL))
            {
                cerr << "error:unable to read from named pipe" << endl;
                break;
            }
            _strupr(textBuffer);
            if(!WriteFile(msnPipe,textBuffer,strlen(textBuffer)+1,&numBytesWritten,(LPOVERLAPPED)NULL))
            {
                cerr << "error:unable to write to named pipe" << endl;
                break;
            }
            cout << textBuffer <<endl;
        }
        FlushFileBuffers(msnPipe);
        DisconnectNamedPipe(msnPipe);
        CloseHandle(msnPipe);
    }
    #define MAX_INSTANCES 3
    void mainServer()
    {
        HANDLE msnPipe;
        DWORD msnpThread;
        while(1)
        {
            msnPipe=CreateNamedPipe("\\\\.\\pipe\\msnp",PIPE_ACCESS_DUPLEX,PIPE_TYPE_BYTE | PIPE_WAIT,
                                    MAX_INSTANCES,0,0,150,(LPSECURITY_ATTRIBUTES)NULL);
     
            if(msnPipe== INVALID_HANDLE_VALUE)
            {
                cerr << "Error: Unable to create a named pipe " << endl;
                continue;
            }
     
            if(!ConnectNamedPipe(msnPipe,(LPOVERLAPPED)NULL))
            {
                cerr << "Error: Unable to connect a named pipe " << endl;
                CloseHandle(msnPipe);
                return ;
            }
            msnpThread = _beginthread(msnpClientThread,0,(HANDLE)msnPipe);
            if(msnpThread==-1)
            {
                cerr << "Error : Unable to create Thread " << endl;
                CloseHandle(msnPipe);
            }
        }
    }
    // client
    void mainClt()
    {
        HANDLE msnPipe;
        DWORD numBytesRead;
        DWORD numBytesWritten;
        char textToSend[128];
        char textRecvd[128];
        char machineName[80];
        char pipeName[80];
     
        cout << "enter Name of server machine";
        cin >> machineName;
        wsprintf(pipeName,"\\\\%s\\pipe\\msnp",machineName);
        msnPipe=CreateFile(pipeName,GENERIC_READ | GENERIC_WRITE,0,
                (LPSECURITY_ATTRIBUTES)NULL,
                OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,(HANDLE)NULL);
        if(msnPipe==INVALID_HANDLE_VALUE)
        {
            cerr << "Error: Unable to connect a named pipe " << endl;
            return ;
        }
        while(1)
        {
            cout << "type text to send:";
            cin.getline(textToSend,128);
            if(!WriteFile(msnPipe,textToSend,strlen(textToSend)+1,&numBytesWritten,(LPOVERLAPPED)NULL))
            {
                cerr << "error:unable to write to named pipe" << endl;
                CloseHandle(msnPipe);
                return ;
            }
            if(!ReadFile(msnPipe,textRecvd,128,&numBytesRead,(LPOVERLAPPED)NULL))
            {
                cerr << "error:unable to read from named pipe" << endl;
                CloseHandle(msnPipe);
                return ;
            }
            cout << "Received :" << textRecvd << endl;
        }
    }
    adaptable pour tester la connexion .


  3. #3
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    non, en fait j'ai d�j� test� pour les lectures �critures de pipe, et j'obtiens toujours 0 ms pour toutes les op�rations....

    NB: mes messages sont des paquets de taille fixe de 220 octets.

    En fait, j'ai mesur� unitairement le temps de toutes mes fonction; j'obtiens toujours 0ms de temps d'execution (pour lire puis empiler, d�piler et �crire...etc).
    Il semblerait que ce soit un temps de latence, un mauvais ordonnancement dans mes threads, pourtant, encore une fois, je ne trouve pas de zone de ralentissment dues � mes sections critiques!!!

    Le fait de lancer flash augmente de mani�re consid�rable l'utilisation du processeur par mes process, comme si mon prog �tait fain�ant, mais qu'il retrouvait du poil de la b�te quand on lance flash!!!

    En tous cas merci.
    Yverain

  4. #4
    R�dacteur
    Avatar de farscape
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    Novembre 2003
    Messages
    9 055
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : High Tech - �diteur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 9 055
    Par d�faut
    comment tu suspends tes threads ?

  5. #5
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    En fait, j'ai une section critique par file:
    j'entre dans ma section critique quand j'empile (quand je re�ois un message) et quand je d�pile (quand j'envoi un message)...

  6. #6
    Expert confirm�

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 756
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 43
    Localisation : France, H�rault (Languedoc Roussillon)

    Informations professionnelles :
    Activit� : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 756
    Billets dans le blog
    3
    Par d�faut
    Tu as du code d'IHM dans tout �a ?
    Note que tous ces thread je trouve �a un peu usine � gaz. Pourquoi 3 thread par client sur le serveur ? Le thread qui lit le pipe peut pas envoyer directement sur le client qui va bien ? Avec un seul thread pour tous les clients ? Si l'�criture blocante du pipe te g�ne utilise le mode overlapped, l'�criture ne sera plus blocante.

  7. #7
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    Je suis dans le cadre d'informatique industrielle et supervision, le fait est que je dois r�pondre en presque temps r�el (Je sais, pas de remarque sur windows pour le temps r�el...) � de grosses sollicitations.. et le fait d'avoir 3 thread permet un empilement au niveau d'une file (liste chain�e) qui est de taille infinie, contrairement au buffer du pipe nomm� qui est fini et qui ne bloque, contrairement � ce que les gens pensent, qu'en �criture. Le fait d'avoir un pipe non bloquant en �criture et de taille finie implique, si on fonctionne sur un seul thread entraine une perte partielle des messages (en fait 20% de pertes dans l'ancienne architecture que j'ai reprise).

    En effet, le fait de faire une lecture sur un thread se r�sume a effectuer s�quentiellement la tache:

    lecture
    -
    traitement
    -
    �criture

    si les op�rations de lecture �criture sont de dur�e fixe (car les messages sont de taille fixe), le traitement quant � lui est de dur�e variable car il est souvent l'occasion d'acc�s � un programme et pendant ce traitement, les clients envoient encore des donn�es.

    Ceci induit donc la deuxi�me probl�matique du serveur de communication; Le serveur de communication fonctionnant de mani�re synchrone (une requ�te induit obligatoirement une r�ponse) sur des op�rations de lecture �criture, il est n�c�ssaire de pouvoir hautement parall�liser les traitement afin d'obtenir une disponibilit� maximum.

    Si on rajoute � �a l'existance de "triggers" sur le server, qui envoient des messages de modification de valeurs du serveur au clients, et ce de mani�re asynchrone (un message n'induit pas de r�ponse), on comprend alors tout l'int�r�t de la multiplication des threads.

    En r�sum�, les tests effectu�s d�montrent que plus les taches susceptibles de p�naliser les performances de l'outil de comm sont parall�lis�es, plus le serveur de comm est performant.

    Maintenant, la question est de savoir ce qui p�nalise mon serveur, et pourquoi une interraction avec le logiciel flash le boost, mais mes connaissance actuelle ne mon pas permis de mettre le doigt sur la solution.

    Ma derni�re th�orie en date �tait que les temps de repos(Sleep uniquement) �tait trop court, et que le process passait en NOPE puis reprennait la main de suite, sans faire de changement de thread. et que le fait de lancer flash, de priorit� plus �lev�e finissait par forcer ces changements de thread.

    Capilotract� n'est il pas.... et totallement incorrect...

    J'ai completement us� mes cellules grises, je vais me pendre de suite!!!

    Danke, thanks
    Yverain

  8. #8
    R�dacteur
    Avatar de farscape
    Homme Profil pro
    D�veloppeur informatique
    Inscrit en
    Novembre 2003
    Messages
    9 055
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : D�veloppeur informatique
    Secteur : High Tech - �diteur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 9 055
    Par d�faut
    ou tu utilises des sleeps et dans quel but (possible que le probleme vienne de la ) ?

  9. #9
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    j'utilise des slips (d�sol�)quand je suis dans les cas ou je dois sauvegarder du temps processor, par exemple lors des boucles de lecture:
    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    tant que pipe_ouvert
        taille = lecture(message);
        si taille > 0 alors
             empiler(message,pile_lecture);
        sinon
            Slip(1ms);
        Fin si
    fin tant que
    des boucles d'�criture:
    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    tant que pipe_ouvert
        si non pile_est_vide alors
        message = depiler(pile_ecriture)
        ecriture(message );
        sinon
            Slip(1ms);
        Fin si
    fin tant que
    des boucles de traitement:
    Code : S�lectionner tout - Visualiser dans une fen�tre � part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    tant que pipe_ouvert
        si non pile_est_vide alors
        message = depiler(pile_lecture)
        reponse = traiter(message );
        empiler(reponse,pile_ecriture);
        sinon
            Slip(1ms);
        Fin si
    fin tant que
    voili voilou...

    normalement, en cas de charge, le CPU doit �tre entierement utilis�... mais ce n'est pas le cas... le probleme est qu'il y a encore une surcouche avec la partie connexion au progiciel et qu'en fait , le nombre de taches parall�les est sommes toute assez important.

  10. #10
    Expert confirm�

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 756
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 43
    Localisation : France, H�rault (Languedoc Roussillon)

    Informations professionnelles :
    Activit� : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 756
    Billets dans le blog
    3
    Par d�faut
    contrairement au buffer du pipe nomm� qui est fini et qui ne bloque, contrairement � ce que les gens pensent, qu'en �criture
    Par d�faut. Mais Windows supporte la lecture / �criture asynchrone. Dans ce mode, un ReadFile / WriteFile rendra tout de suite la main, et ta demande de lecture / �criture sera mise en attente, dans une file, g�r�e par Windows...
    http://msdn.microsoft.com/library/en-us/ipc/base/synchronous_and_overlapped_input_and_output.asp
    Tu as plusieurs techniques.
    http://www.sysinternals.com/Information/IoCompletionPorts.html
    http://www.codeproject.com/internet/IOCompletionPort.asp
    http://www.codeproject.com/internet/IOCP_Server_client.asp


    il est n�c�ssaire de pouvoir hautement parall�liser les traitement afin d'obtenir une disponibilit� maximum.

    Si on rajoute � �a l'existance de "triggers" sur le server, qui envoient des messages de modification de valeurs du serveur au clients, et ce de mani�re asynchrone (un message n'induit pas de r�ponse), on comprend alors tout l'int�r�t de la multiplication des threads.
    oui mais faut pas trop cr�er de threads quand m�me, car �a coute � force.

    Maintenant, la question est de savoir ce qui p�nalise mon serveur, et pourquoi une interraction avec le logiciel flash le boost, mais mes connaissance actuelle ne mon pas permis de mettre le doigt sur la solution.
    A priori pas de raison. A part au niveau du code d'IHM je vois pas trop. C'est pour �a que je te demande:
    - as-tu du code d'IHM ? A quel niveau ?
    En tous cas, AMHA, l'erreur est d'avantage dans ton code que dans celui de l'ordonnanceur de Windows.

    j'utilise des slips
    �a fonctionne comment ? Normalement tu n'en n'as pas besoin.

  11. #11
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    En tous cas, AMHA, l'erreur est d'avantage dans ton code que dans celui de l'ordonnanceur de Windows.
    la dessus, on est d'accord, mais le fait que l'appli accelere quand flash est lanc� doit normalement nous donner un indice sur la raison de la lenteur. Je me posais donc des questions sur la fa�on dont fonctionnait l'ordonnanceur. En effet, tous les tests effectu�s montre que le temps de latence est du � des temps d'inactivit� du processus...

    - as-tu du code d'IHM ? A quel niveau ?
    non, tout fonctionne en mode console de la m�me mani�re qu'avec un IHM, je m'�tais pos� la question moi aussi.

    Pour ce qui est des Sleep(slip), je suis oblig� dans avoir au moins dans les boucles d'�criture. sinon, j'utilise 100% du cpu et c'est pas top.

    Pour le pipe overlapped, je connais,mais la specification fonctionnelle du systeme dans lequel j'integre le serveur de communication m'impose de travaille en mode synchrone sur la majorit� des �critures.(NB: je n'utilise les pipes qu'en local d'ailleur), et en termes de performances, c'est pas forcement ce que j'attends....
    En fait mon client passe vraiment un grand nombre de demande (de l'ordre de 1 ou 2 � la ms en cas de cascade) et, m�me si le pipe est configur� en bloquant aucune des �critures n'est bloqu�e quand le pipe atteind sa taille maximal (65635 o il me semble, � v�rifier dans la msdn) d'ou un �crasement des donn�es si le pipe n'est pas vid� tout de suite.(� v�ifier pour le pipe overlapped, ce que je vais faire de ce pas...)

  12. #12
    Expert confirm�

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 756
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 43
    Localisation : France, H�rault (Languedoc Roussillon)

    Informations professionnelles :
    Activit� : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 756
    Billets dans le blog
    3
    Par d�faut
    A chaque Sleep( 0 ) tu paumes 10 ms.

  13. #13
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    mais si je ne les fais pas, le probleme c'est que je bouffe toutes les ressources processeur

  14. #14
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut
    je viens de voir...

    Sleep(0) ne te fais pas perdre de temps...
    Il sert � reprendre le processeur/ordonnanceur, et fait bourriner le process(cf msdn)

    Sleep( 1) je te l'accorde, � une latence sup�rieure � 1 ms. mais est n�cessaire...

  15. #15
    Membre confirm�
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    D�tails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par d�faut j'ai essay� en synchronisant
    ...tout avec des events, et il semblerait que �a marche... il me reste juste un l�ger interbloquage, mais �a je devrais trouver seul 8)

    En tous cas merci pour votre aide et � bient�t
    Yverain

+ R�pondre � la discussion
Cette discussion est r�solue.

Discussions similaires

  1. probleme avec ecriture de pipe nomm�
    Par Rhapso59 dans le forum C
    R�ponses: 0
    Dernier message: 24/04/2009, 16h24
  2. Problème de vitesse lors de recherche de carré magique
    Par niniwizard dans le forum Prolog
    R�ponses: 22
    Dernier message: 16/01/2009, 13h11
  3. Probleme de vitesse de transfert ..
    Par Nemesys dans le forum Hardware
    R�ponses: 8
    Dernier message: 23/05/2006, 16h08
  4. Problème de vitesse de tranfert USB
    Par HNT dans le forum Mat�riel
    R�ponses: 10
    Dernier message: 15/04/2006, 14h55
  5. R�ponses: 3
    Dernier message: 16/03/2004, 16h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo