Version imprimable
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
Ce sont les options de performances de Windows qui allouent plus de ressources processeurs aux programmes qu'aux services d'arrière-plan.
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)