Perform ances de LSC
Transcription
Perform ances de LSC
Concerne les volumes importants… Pour permettre de répondre précisément aux différentes questions sur les performances de LSC avec des volumes importants, nous avons effectué des mesures dans différentes configurations. Les résultats obtenus doivent servir d’étalon à toute configuration. Cet étalonnage a été réalisé en Avril 2001. Descriptif de la configuration de test. Réseau : 100 BT avec un commutateur. Serveur 1 Volontairement, nous avons choisi une machine obsolète d’entrée de gamme. Il s’agit d’un serveur IBM Netfinity 3 500, Pentium II à 333 Mhz avec un disque dur SCSI standard, NT 4.0 et 192 Mo de RAM (configuration à 3 000 € en 1998, plus NT 4.0). Serveur 2 Nous avons sélectionné une machine adaptée à LSC. Serveur Dell PowerEdge 2 400, Pentium III à 933 Mhz, 2 disques durs de 15 Go rapides (15 000 tr/mns) montés en RAID 0, Windows 2000 Serveur et 256 Mo de RAM (configuration à 3 800 Euros en 2001, plus Windows 2000). Postes clients Les mesures sont effectuées dans un environnement hétérogène, avec des clients sous configurés. - Pentium II Mmx, 200 Mhz, 64 Mo de RAM sous Win 98 ! - Imac 266, 96 Mo de RAM - Portable PowerBook G3, 192 Mo de RAM Réglages Windows et LSC Serveur (standards pour une machine dédiée à LSC) - CPU maximum à l’application de premier plan - LSC (programme) est mis sur une partition, les données sur une autre partition - Réglage mémoire de 4D Serveur : 6 blocs de 16 384 et cache de 120 Mo - CPU est réglé sur 2/20/0 pour rendre LSC coopératif : CPU en inactivité = 20% (volontairement nous n’avons pas laissé le réglage par défaut 5/1/0 qui donne de meilleures performances mais monopolise en permanence 90% des ressources). Volume de tests Les tests sont effectués sur le module Gérance avec les volumes suivants : 1200 lots, 1100 mandats, 1000 locataires présents (500 partis), 300 000 lignes d’écritures comptables, 40 000 événements mémorisés. Préalables Les mesures ne sont pas effectuées à la première opération, car LSC effectue une mise en cache des informations et cette mesure n’est pas significative. Quelques rappels : 1- Préalable sur le fonctionnement de la base de données et du cache mémoire. - Les informations demandées au serveur sont mises en cache, ce qui explique qu' après une première mise en cache de l' information, toute nouvelle demande devient quasi-instantanée. - Donc, lorsque la base est en exploitation, les performances s' améliorent au fur et à mesure du remplissage du cache. - Quand cela est nécessaire, le cache est écrit sur le disque dur (phénomène de flush). Au moment du flush, un ralentissement général se fait sentir. Le cache est un point extrêmement important dans le bon fonctionnement du serveur. Réf. : 0144 - 09/01/2006 - 1/4 Crypto Nancy l 25, rue de Saurupt l BP 70655 l 54063 Nancy Cedex l Tél. : 03 83 90 36 36 l Fax : 03 83 90 16 06 Crypto Paris l 35, rue Damrémont l 75018 Paris l Tél. : 01 42 74 25 36 Crypto Atlantique l 218, impasse de Germinal l 85440 Talmont Saint-Hilaire l Tél. : 02 51 21 63 68 EURL au capital de 100 000 € - APE 722 A - RCS 347 770 158 - SIRET 347 770 158 00041 - TVA : FR 20 347 770 158 2- Utilisation de travaux simultanés Certains traitements de masse sont gérés par LSC en process serveur. Cette terminologie signifie que le poste client transfère l' ordre d' exécution au serveur, qui assume, par conséquent l' intégralité du traitement. Le serveur fonctionne en mode coopératif, les différents process se partageant ses ressources. Dans le cas de traitements simultanés, il est tout à fait normal que les performances générales soient diminuées. Les traitements serveurs sont limités aux travaux suivants : - Relances d' impayés - Appels de fonds et répartition des charges - Et à moindre mesure : lettrages des comptes et clôtures. Plus la machine serveur est efficace, plus ces traitements sont directement améliorés. Dans la mesure du possible, il est déconseillé de lancer ces traitements pendant une utilisation intensive du serveur ! Résultats 1 - Opérations concernant l’interface et la gestion des écrans. Tests Crypto Tests Crypto sur IBM NetFinity 3500 sur Dell 2400 F1 - apparition de l' écran <à1s <à1s F1 - validation d' un courrier <à1s <à1s RV création et affichage sur planning <à1s <à1s F7 ou historique des événements 2s <1 s Ces mesures étalonnent les temps d’apparition d’un écran ou le temps nécessaire pour le dessin de la fenêtre après une action. Le serveur influe peu sur ces performances. Par contre, le poste client est très important sur ces mesures (qui peuvent aller du simple au triple). Ces performances sont globalement indépendantes des volumes. 2 - Traitements comptables Serveur1 Serveur2 sur IBM NetFinity 3500 sur Dell 2400 Ecritures non pointées : 678/26313 2s 2s Ecritures pointées : 25 637 25 s 5s Somme=Dette 8s 3-4 s Somme<Dette 4s 3-4 s Somme>Dette 8s 4-5 s 2s <1 s Rapprochement Bancaire Saisie comptable Consultation de compte Le gain obtenu avec le serveur 2 devient significatif. Un rapport de 5 pour les écritures pointées, et un rapport de 2 en saisie comptable. De plus, ces mesures dépendent directement des volumes. Dans notre jeu d’essai, nous avons plus de 300 000 lignes d’écritures comptables. En prenant un volume de 50 000 lignes, les temps de traitement sont inférieurs à 1 secondes. NB : en saisie Syndic ou Comptabilité générale les saisies sont instantanées. Ces temps sont meilleurs sur les postes clients les plus performants Réf. : 0144 - 09/01/2006 - 2/4 Crypto Nancy l 25, rue de Saurupt l BP 70655 l 54063 Nancy Cedex l Tél. : 03 83 90 36 36 l Fax : 03 83 90 16 06 Crypto Paris l 35, rue Damrémont l 75018 Paris l Tél. : 01 42 74 25 36 Crypto Atlantique l 218, impasse de Germinal l 85440 Talmont Saint-Hilaire l Tél. : 02 51 21 63 68 EURL au capital de 100 000 € - APE 722 A - RCS 347 770 158 - SIRET 347 770 158 00041 - TVA : FR 20 347 770 158 3 - Impressions Serveur1 Serveur2 sur IBM NetFinity 3500 sur Dell 2400 Revenu foncier 15 s 5s Impression relevé de G :1er relevé 8s 4s Le gain obtenu avec le serveur le plus puissant présente un rapport de 2 à 3. Attention à ne pas mal interpréter ces mesures ; en effet, ces impressions constituent une présentation sophistiquée des écritures comptables. Le temps de traitement correspond au temps de construction de l’état complexe. Le serveur ne va influencer que les états complexes qui sollicitent grandement les données. Les temps d’impression d’un courrier simple restent inchangés quel que soit le serveur. 4 - Traitements de masse 1er exemple : Relance d’impayés sur 1 000 locataires. Relance d' impayés Tests Crypto Tests Crypto sur IBM NetFinity 3500 sur Dell 2400 10 mns 3 mns Nous retrouvons un facteur 3 entre les 2 serveurs. 2ème exemple : Calcul d’honoraires sur 1 000 propriétaires, fin de trimestre. Test effectué uniquement sur le serveur 2. Nous obtenons un temps de moins 10 minutes. 3ème exemple : Répartition des charges. Test effectué sur les volumes suivants : 100 copropriétaires, 350 lots, 20 clés de répartition et 130 comptes de charges. Ce traitement offre la possibilité d’exécuter le traitement en local (sur le poste client) ou de déporter cette tâche sur le serveur. Les résultats obtenus sont significatifs (les mesures ont été effectuées sur le serveur 2). Avec l’option « Exécuter en local » : 3 minutes et 30 secondes. Dans ce cas de figure, le serveur est utilisé de manière « légère » et les autres utilisateurs peuvent travailler avec une dégradation tolérable des performances. Avec l’option « Exécuter sur le serveur » : 1 minute 15 secondes. Avec cette option, le serveur est sollicité à plein et les autres utilisateurs sont très fortement pénalisés. Le choix de l’option appartient à l’utilisateur en fonction de l’environnement. Conclusions sur les traitements de masse Ces traitements sollicitent à plein les ressources du serveur et les autres utilisateurs sont pénalisés pendant ces traitements. Il convient de s’organiser pour ne pas lancer ces traitements dans un pic d’activité. D’une manière exhaustive, ces traitements sont : En Gérance - appels de loyer - calcul d’honoraires En Syndic - appel de fonds et répartition de charges En Comptabilité (Gérance et Syndic) - relance d’impayés - Lettrage de masse - clôture d’exercice. Réf. : 0144 - 09/01/2006 - 3/4 Crypto Nancy l 25, rue de Saurupt l BP 70655 l 54063 Nancy Cedex l Tél. : 03 83 90 36 36 l Fax : 03 83 90 16 06 Crypto Paris l 35, rue Damrémont l 75018 Paris l Tél. : 01 42 74 25 36 Crypto Atlantique l 218, impasse de Germinal l 85440 Talmont Saint-Hilaire l Tél. : 02 51 21 63 68 EURL au capital de 100 000 € - APE 722 A - RCS 347 770 158 - SIRET 347 770 158 00041 - TVA : FR 20 347 770 158 5) Courriers Les courriers sont réalisés en 2 étapes : - création des courriers et affichage dans une liste - impression des courriers. Sur le serveur 1, les temps sont environ de 4 secondes par étape et par courrier et ils sont de 2 secondes sur le serveur 2. Les courriers sollicitent d’une manière soutenue le client et le serveur. Les autres utilisateurs peuvent être ralentis dans le cas d’un traitement de masse important. Conclusions sur les performances Les performances que nous obtenons peuvent servir d’étalon en configuration réelle de LSC. En cas de divergence, il convient d’optimiser sa configuration en veillant plus particulièrement aux points suivants : LSC doit être sur un serveur dédié et il est impensable de déléguer d’autres tâches au serveur Crypto qui doit déjà gérer : - L’application LSC - La gestion des mails (option) - L’expédition des fax (option) Veillez à ne pas activer sur le serveur d’autres services (partage de fichiers, serveur d’impression, antivirus, etc…) Il est possible de faire fonctionner un logiciel de sauvegarde sur ce serveur, à condition que la sauvegarde s’exécute en dehors des heures habituelles de travail. Le serveur doit être équipé de disques durs rapides. Le serveur 2 possède 2 disques durs SCSI à 15 000 tours/minute montés en RAID 0. Attention au système RAID choisi. Le RAID 5 est un système de sécurisation des données en cas de crash disque. Le RAID 0 est un système de répartition des données sur différents disques. C’est un système d’optimisation des performances au détriment de la sécurité en cas de crash disque. Cependant, la sécurité peut-être assurée par un système de sauvegarde adapté. De RAM : plus la RAM est importante, plus il sera possible d’affecter de la mémoire cache. La taille nécessaire de la mémoire cache dépend directement des volumes et des configurations. Il n’est pas possible de définir une mesure absolue. L’idéal étant de pouvoir affecter un cache proche de la taille de votre fichier de données. Dans notre test, le cache est de 120 Mo alors que le fichier de données pèse 500 Mo. Nous aurions amélioré les performances en augmentant ce cache. Ne pas négliger le poste client : il influence grandement les performances pour tous les traitements effectués en local : amélioration directe des temps d’affichage des écrans. Passer de 1 seconde à quelques fractions de secondes pour afficher un écran n’est pas significatif dans l’absolu. Cependant la « perception utilisateur » attache beaucoup d’importance à cette différence et l’application pourra être qualifiée de lente ou rapide en fonction de ces quelques dixièmes de secondes. De plus, le poste client influence grandement la rapidité d’impression ou les calculs (exemple calcul d’honoraires). le réseau : en fonction des volumes, le gain peut être significatif entre un réseau 10 BT ou 100 BT. Mieux, si le nombre d’utilisateurs est supérieur à 5, il convient de remplacer le HUB passif par un commutateur actif, ce qui va limiter et optimiser le transit réseau. Réf. : 0144 - 09/01/2006 - 4/4 Crypto Nancy l 25, rue de Saurupt l BP 70655 l 54063 Nancy Cedex l Tél. : 03 83 90 36 36 l Fax : 03 83 90 16 06 Crypto Paris l 35, rue Damrémont l 75018 Paris l Tél. : 01 42 74 25 36 Crypto Atlantique l 218, impasse de Germinal l 85440 Talmont Saint-Hilaire l Tél. : 02 51 21 63 68 EURL au capital de 100 000 € - APE 722 A - RCS 347 770 158 - SIRET 347 770 158 00041 - TVA : FR 20 347 770 158