RECHERCHE ET DEVELOPPEMENT SAGE 100

Objet : Dégradation des performances en utilisation de Sage Paie Windows &

Sage Serveur

Nous avons détecté différents cas de figure impactant les temps de réponse lors de l’utilisation
de Sage Paie en réseau.

1. Le client dispose d’une version monoposte de la Paie mais fonctionne en multipostes

du fait de la cohabitation avec des versions Sage 100 réseau.
2. Le client dispose d’une configuration ne permettant pas au protocole réseau TCP/IP de
fonctionner correctement.
3. Le paramétrage de Sage Paie et le contenu de la base Paie ont un impact sur les
performances, particulièrement sensible sur le jeu d’essai (Essai.PRH).
4. Le mode d’ouverture de la base (URL réseau ou accès disque) impacte également les
performances en utilisation locale.
5. Le paramétrage des cartes réseau en termes de taux de gestion des interruptions

Problématique 1
Le client dispose d’une version monoposte de la Paie mais fonctionne en multipostes du
fait de la cohabitation avec des versions Sage 100 réseau.

Les versions 16 de l’offre Sage 100 ont introduit la notion d’installation « side by side ». A
partir de ces versions, il n’est plus possible pour deux applications différentes de fonctionner
différemment.

Si sur un poste client cohabitent une application Sage 100 réseau et Sage Paie monoposte,
et si les données de la Paie sont hébergées sur le même serveur que les données Sage 100
(avec le Serveur Sage),
Alors Sage Paie devient également réseau avec des bénéfices en termes de sécurité mais un
impact en termes de performance.

Recherche & Développement Sage 100 page 1

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Exemple : Poste client Seven – Serveur Windows 2008 Server 32 Bits

Sans Avec
Traitement réalisé sur base Essai.PRH v18 convertie v19 Serveur Serveur
Sage Sage
Edition des bulletins - 37 bulletins Nov 2009 00:00:30 00:03:20

Edition du livre de paie annuel 2009 00:00:13 00:01:19

Affichage onglet Valeur de base sur Salarié N° 1000 ou 3000 ou 7103 00:00:01 00:00:02

Affichage de la page Contrat sur salrié N° 7103 00:00:01 00:00:01

Dans les versions précédentes, il suffisait de copier la DLL CbaseLocal.DLL dans le répertoire
d’installation de Sage Paie pour régler le problème. Cette solution n’est plus applicable.

Solutions proposées
Avant la version 20.50 de Sage Paie, deux solutions étaient de :
- Déplacer les données de la Paie sur un serveur différent de celui utilisé par les applications
Sage 100 (serveur non équipé de Sage Serveur), ou
- Déplacer l’application Paie sur un poste ne disposant pas des applications Sage 100.

En version 20.50, sur un poste client disposant d’applications Sage 100 réseau, il est
désormais possible d’utiliser Sage Paie version monoposte en accès sans Sage Serveur.

La présence de Sage Serveur sur le poste n’impacte alors plus les performances de Sage Paie.

Il suffit pour cela de cocher l’option Monoposte accessible par le menu : Fichier / Droits
d’accès / Paramètres de connexion

Recherche & Développement Sage 100 page 2

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Problématique 2
Le client dispose d’une configuration ne permettant pas au protocole réseau TCP/IP de
fonctionner correctement.

Le Serveur Sage peut fonctionner en utilisant deux protocoles réseaux :

- Le protocole TCP/IP pour des performances optimales,
- Les canaux nommés.

Par défaut les applications utilisent en premier le protocole TCP/IP pour se connecter au
serveur Sage si cela est possible.
Dans le cas où le protocole TCP/IP ne leur permet pas de se connecter au Serveur Sage, les
applications basculent ensuite sur le protocole canaux nommés (Netbeui) avec un impact sur
les performances :

Exemple : Poste client Seven – Serveur Windows 2008 Server 32 Bits

Serveur Serveur
Traitement réalisé sur base Essai.PRH v18 convertie v19 Sage Sage
TCP/IP Netbeui
Edition des bulletins - 37 bulletins Nov 2009 00:03:20 00:13:21

Edition du livre de paie annuel 2009 00:01:19 00:05:44

Affichage onglet Valeur de base sur Salarié N° 1000 ou 3000 ou 7103 00:00:02 00:00:07

Affichage de la page Contrat sur salarié N° 7103 00:00:01 00:00:01

Solution proposée
A l’heure actuelle, la solution immédiate est de diagnostiquer la défaillance du protocole
TCP/IP en utilisant la commande NetStat, puis de procéder à son rétablissement
(réinstallation, contrôle antivirus, firewall,…).
L’utilitaire Windows NTTCP permet également de vérifier les performances du réseau.

Le serveur Sage dans sa prochaine version i7 indiquera le mode d’accès dans la console des
utilisateurs connectés.

Par ailleurs, en version 20 de la paie, il est possible de visualiser le protocole utilisé, dans la fenêtre
Préférences du menu Fichier, si un fichier de paie est ouvert.

Recherche & Développement Sage 100 page 3

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Recherche & Développement Sage 100 page 4

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Problématique 3
Le paramétrage de Sage Paie et/ou le contenu de la base Paie ont un impact sur les
performances (particulièrement sensible sur Essai.PRH).

Les relevés de temps ont eu lieu dans différentes configurations pour cibler la mise à jour à
l’origine des dégradations de temps.
Configuration auditée Dégradation
Calcul des 37 bulletins Essai.PRH v18 – Essai PRH v18 converti – Essai PRH v19 temps
Paie 18.5 avec Serveur 15.5 vs Paie 18.5 avec serveur 16.05– Essai.PRH v18 Aucune
Paie 19.5 avec Serveur 15.5 vs Paie 19.5 avec serveur 16.05 – Essai.PRH v18 convertie Aucune
Paie 18.5 avec Serveur 16.05 vs Paie 19.5 avec serveur 16.05 – Essai.PRH v18 et conv. Environ + 20%
Paie 18.5 avec Serveur 16.05 vs Paie 19.5 avec serveur 16.05 – Essai.PRH v19.50 Environ + 90%

On constate une dégradation des temps en version 19.50 directement liée à :

- La version 19.50 de Sage Paie,
- Le contenu de la base de données PRH et son paramétrage.

Exemples:

Paie 19.5 Paie 19.5

Paie 18.5
Traitement en local sans Serveur Sage Essai PRH 18.5 Essai PRH
Essai.PRH 18.5
converti 19.5
Edition des bulletins - 37 bulletins - Novembre 00:00:26 00:00:30 00:01:10

Paie 19.5 Paie 19.5

Paie 18.5
Traitement réseau avec Serveur Sage Tcp/Ip Essai PRH 18.5 Essai PRH
Essai.PRH 18.5
converti 19.5
Edition des bulletins - 37 bulletins - Novembre 00:02:50 00:03:30 00:05:23

Les différences de temps constatées entre le jeu d’essai V18.50 et le jeu d’essai V19.50 sont
liées à la mise en place sur le jeu d’essai V19.50, des nouveaux paramétrages d’absences et
d’estimation des IJSS maladie, maternité et AT. A noter qu’il n’y a pas de « calculs à l’envers »
sur le jeu d’essai V19.50, et que les temps de calculs sont exclusivement liés au nombre de
constantes et rubriques nécessaires pour automatiser ces règles de calculs complexes d’IJSS
car elles varient selon le type d’arrêt de travail…

Recherche & Développement Sage 100 page 5

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Solutions proposées
Il faut donc vérifier si de nouveaux paramétrages n’ont pas été implémentés dans le dossier
du client, et en particulier celui sur les absences et les IJSS.

Si le client a mis en place ses propres paramétrages, un moyen rapide d’évaluer la complexité
de son plan de paie est de demander un aperçu avant impression du bulletin avec traces d’un
salarié « significatif » et de regarder combien de pages il y a dans le rapport.
Pour avoir quelques repères (avec le salarié « Pousse ») :
- sur le jeu d’essai 18.50 (donc avant mise en place du paramétrage maladie) : 116 pages
- sur le jeu d’essai 19.50 (donc incluant le paramétrage maladie) : 161 pages

Une dernière piste pouvant expliquer des temps de calculs longs est le lancement de calcul de
« paie à l’envers » (qui peuvent parfois se déclencher automatiquement suivant les
paramétrages mis en place dans le dossier du client).

En paie version 20.50, l’option Valorisation a été ajoutée sur tous les types de constantes, sauf
message et nature.
Cette option permet d’éviter les calculs multiples et rapports avec trace très longs.

2 choix sont possibles :

- A chaque appel : la constante se calculera à chaque appel dans le bulletin de paie et le

rapport avec trace contiendra le détail des calculs lors de chaque utilisation de cette
constante.
- Au 1er appel : la constante ne se calculera que lors du premier appel dans le bulletin et le
rapport avec trace ne contiendra le détail des calculs que lors de sa première utilisation.
Lors des utilisations suivantes, le rapport avec trace indiquera directement le résultat de la
constante.

Dans le cas d’une constante pour laquelle le rapport avec traces présente plusieurs pages de
calculs et étant appelée plusieurs fois dans le bulletin, la seconde option permet de diminuer
significativement la longueur du rapport. De plus, cette constante ne se calculera qu’une seule
fois lors du calcul du bulletin.

Recherche & Développement Sage 100 page 6

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Problématique 4
Le mode d’ouverture de la base (URL réseau ou accès disque) impacte les performances en
utilisation locale.

Exemples:
Accès via URL réseau Accès disque
Traitement réalisé en local sans serveur Sage
\\nom poste\partage\bases C:\répertoire\Base

Edition des bulletins - 37 bulletins Nov 2009 00:00:36 00:00:20

Solution proposée
Pour une utilisation en mode local (sur la même machine), préconiser l’accès au fichier via un
accès disque.

Recherche & Développement Sage 100 page 7

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Problématique 5
Un paramètre des cartes réseau a été identifié comme influant de manière significative
(environ 30 %) sur les temps d’édition/de calcul des bulletins de la Paie.

Ce paramètre nommé « Taux de gestion des interruptions » ou « Modération

interruptions » (ITR – Interrupt Throttle Rate) détermine le taux auquel les interruptions de
transmission et de réception des paquets réseau sont générés. D’une manière générale, un
taux ITR élevé génère une latence plus importante du pilote de la carte lors du traitement des
paquets. De plus, si la carte traite de nombreux petits paquets (cas lors de l’édition/calcul de
bulletins), il est préférable de diminuer l’ITR afin que le pilote puisse répondre plus
efficacement aux paquets entrant et sortant.

Par défaut, après installation du pilote de la carte réseau, ce paramètre est placé sur la valeur
« Variable » (ITR = 65536). Dans cette configuration, les temps relevés pour l’édition des 38
bulletins de la base Essai.prh fournie avec la Paie v20, s’élèvent à 10 – 11 minutes environ.

En désactivant le paramètre de taux de gestion des interruptions (ITR = 0), le temps d’édition
de ces 38 bulletins s’effectue alors en environ 6 minutes.

Ci-dessous sont détaillés les configurations des postes de test, ainsi que les temps relevés
suivant l’activation/désactivation du paramètre ITR sur le poste client et sur le poste serveur.

La méthode permettant de désactiver le paramètre ITR sur une carte réseau Intel 82579LM
Gigabit est détaillée en Annexe 1 de ce document.

Configuration des postes de test

OPTIPLEX 790 Poste Serveur Poste Client

Environnement Win 2003 R2 puis Win 2008 R2 Win Seven x64
Processeur Intel Core i7-2600 3.40 Ghz (8 cores) Intel Core i7-2600 3.40 Ghz (8 cores)
Ram 8 Go 8 Go
Carte Réseau Intel 82579LM Gigabit Intel 82579LM Gigabit

Les deux postes sont tous deux membres du même domaine.

Sur le poste Serveur, la Paie V20 complète ainsi que le serveur Sage V17 ont été installés.

Sur le poste client, la partie cliente Paie et la partie cliente de Sage Serveur (accès TCP/IP) ont
été installées.

Recherche & Développement Sage 100 page 8

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Relevés des temps

La base de paie utilisée pour la prise des temps est la base Essai.prh installée par la Paie V20.

Edition des 38 bulletins de la base Essai.prh fournie Poste Client

avec la Paie v20
Poste Gestion des interruptions Variable Désactivée
Serveur Variable 10 à 11 min 8 à 9 min
Désactivée 8 à 9 min 5 min 30 à 6 min 30

Remarque : aucune différence de temps significative n’a été constatée suivant la version de
l’environnement du poste serveur (Win 2003 R2 mis à jour en Win 2008 R2).

Conclusion
Le relevé des temps fait clairement apparaître l’influence du paramètre ITR sur les temps de
calcul/édition des bulletins en mode client/serveur. Les temps d’édition sur la base Essai.prh
étant encore un peu supérieurs à ceux constatés sur une configuration standard, il est
préférable que le client installe la dernière version du pilote de carte réseau disponible.

Recherche & Développement Sage 100 page 9

 RECHERCHE ET DEVELOPPEMENT SAGE 100

Annexe 1 : Désactivation « Taux de gestion des interruptions »

La procédure détaillée ci-après, permet de désactiver le paramètre « Taux de gestion des

interruptions » sur une carte réseau Intel 82579 LM Gigabit. Ce paramètre existe également
sur d’autres marques de cartes, nous vous invitons à désactiver ces paramètres :

- Suivant la version du pilote et de l’outil de configuration de la carte réseau installés sur

le poste, le paramètre « Taux de gestion des interruptions » peut être actif, mais non
configurable graphiquement. Ainsi, il convient avant tout de télécharger et installer
la dernière version du pilote et des outils de gestion de la carte réseau depuis
le site du constructeur / distributeur du poste.
- Ensuite, afficher les propriétés de la connexion réseau : [Panneau de
configuration]\[Centre Réseau et partage]\[Modifier les paramètres de la carte
réseau] :

Recherche & Développement Sage 100 page 10

 RECHERCHE ET DEVELOPPEMENT SAGE 100

- Sélectionner la commande « Configurer » puis se placer sur le volet « Avancé » :

Recherche & Développement Sage 100 page 11

 RECHERCHE ET DEVELOPPEMENT SAGE 100

- Dans la liste des paramètres, sélectionner l’entrée « Options de performances » puis

cliquer sur « Propriétés ».
- Dans la fenêtre de définition des options de performances, sélectionner l’entrée « Taux
de gestion des interruptions » et placer la valeur sur « Désactivé(e) » :

Recherche & Développement Sage 100 page 12

 RECHERCHE ET DEVELOPPEMENT SAGE 100

- Valider toutes les fenêtres et redémarrer le poste.

Ces manipulations (installation de la dernière version du Driver de carte réseau et définition du

paramètre de gestion des interruptions) doivent être réalisées sur TOUS les postes du parc
(Clients ET Serveur)

Important : Ces manipulations ont pour effet de perdre temporairement la connectivité

réseau. Elles doivent donc être réalisées en étant physiquement connecté sur le poste (ne pas
modifier ces paramètres par une prise en main à distance).

En parallèle à ces solutions, nous travaillons sur une optimisation du paramétrage, ainsi que
des performances du logiciel.

Recherche & Développement Sage 100 page 13