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