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

Delphi Discussion :

Execution plus lente en service qu'en application ?


Sujet :

Delphi

  1. #1
    Membre habitué Avatar de jambonstar
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    175
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : Janvier 2006
    Messages : 175
    Points : 161
    Points
    161
    Par défaut Execution plus lente en service qu'en application ?
    Bonjour à tous,

    Je développe actuellement un serveur d'application Datasnap (TCP et REST) sous Delphi 2010.
    Et je viens de constater que la vitesse d'execution est beaucoup plus lente lorsque je compile tout en service (2 DPR differents).

    Est-ce que quelqu'un à déjà eu ce problème ? J'ai beau chercher, je suis à cours de pistes..

    Merci d'avance pour votre aide

    PLUS FORT ENSEMBLE !Et plus joli aussi
    (\ _ /)
    (='.'=) Voici Lapinou.
    (")-(")
    Aidez le à conquérir le monde en le reproduisant.

    http://ashbasket.free.fr

  2. #2
    Rédacteur/Modérateur
    Avatar de Andnotor
    Inscrit en
    Septembre 2008
    Messages
    5 671
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Septembre 2008
    Messages : 5 671
    Points : 13 065
    Points
    13 065
    Par défaut
    Ce sont les options de performances de Windows qui allouent plus de ressources processeurs aux programmes qu'aux services d'arrière-plan.

  3. #3
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    Juillet 2006
    Messages
    13 426
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2006
    Messages : 13 426
    Points : 24 790
    Points
    24 790
    Par défaut
    C'est une question intéressante, comme toi, je test mon Service via un EXE avec une GUI mais sous XE2
    La version Service, je ne l'ai testé qu'au tout début, depuis la mise en production, je ne passe que par la version GUI
    J'effectue tous mes Stress Tests sur la version GUI, le plus souvent en mode Debug lancé par Delphi

    Moi, j'ai noté quelques instabilités de la version GUI en Debug que je n'ai jamais en mode Service ni en mode GUI exécuté hors Delphi
    Semble que le débogueur me provoque des fuites mémoires lorsqu'il inspecte des interfaces ou des strings.

    De plus, la version GUI, je ne la teste que sur un serveur ORACLE de DEV qui est 3 à 10 fois plus lent que celui de PROD selon ce que l'on lance comme requête.
    Sans compter qu'en PROD, le service a sa WM dédiée et qu'en version GUI en DEV, c'est sur mon poste de développement avec Delphi.
    Avec un tel écart, évidemment, je ne me suis jamais aperçu que la version Service était plus lente que la version GUI, car même si c'est 10% de moins rapide, la DB et le contexte d'exécution change tout !
    Par dessus, en mode Debug, j'affiche dans le Journal d'évènement via OutputDebugString un grand nombre de trace ce qui fait chauffer Delphi (qui monte à 25% CPU - 4 Core)

    Quelle est la chute de performance ?
    Comment gères-tu tes Threads ?
    As-tu tenter de jouer avec SetThreadPriority ?
    Quels est la fréquence des requêtes ?
    Accèdes-tu à une DB ?
    Si oui,
    . Quelle Type ? Quel Driver ? Quel Provider ?
    . As-tu une connexion globale, un pool de connexion, une connexion pour chaque client ?


    Depuis que FastMM est intégré à Delphi, a part, si l'on a une application avec un grand nombre de connexion,
    on peut atteindre le plafond des 2000 threads sans trop de perte de performance ce qui était impossible avec l'ancien gestionnaire qui peinait déjà arrive à 16.
    La stratégie d'un thread par client peut-être couteuse en performance, il faut parfois utiliser des pool de thread ce qui compliquent notablement le programme.

    Le Service échange des données via FTP avec un programme de pilotage de Robot (en C#) qui même échange des données avec un Automate programmable
    Les auteurs du programme de pilotage de Robot ont abandonné le mode Service au profit d'application GUI,
    Cela facilite le développement, la maintenance, l'interactivé, le paramètrage ...
    mais j'ignore si ces Experts ont fait aussi ce choix pour un problème de performance (eux aussi le plus couteux c'est l'accès à SQL Server)
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

Discussions similaires

  1. Application plus lente en dehors de Visual Studio.
    Par istace.emmanuel dans le forum Visual Studio
    Réponses: 5
    Dernier message: 31/05/2012, 09h47
  2. Réponses: 0
    Dernier message: 18/11/2011, 10h30
  3. Réponses: 76
    Dernier message: 29/03/2011, 17h15
  4. [Firebird][Optimisation]Plus lent que le BDE!
    Par vincentj dans le forum Débuter
    Réponses: 3
    Dernier message: 07/02/2005, 16h48
  5. DBExpress est plus lent que BDE?
    Par palassou dans le forum Bases de données
    Réponses: 4
    Dernier message: 02/07/2004, 09h39

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