Manuel

Diagnostiquer, résoudre les problèmes de performance

 

Préambule

 

Kentika est constitué d'un ensemble de fonctions très sophistiquées que ce soit au niveau de la structure des données, des recherches, de la gestion des autorisations ou encore du traitement des documents. Des pertes de performances qui seraient imperceptibles dans un environnement simple (cas, par exemple, de la gestion en entrepôts de documents), le deviennent avec Kentika si certaines règles de bonne gestion sont négligées.

Kentika évolue dans un environnement en pertuelle évolution. D'une version à l'autre de Kentika nous nous efforçons d'intégrer les dernières versions des technologies utilisées et de contrer les menaces en provenance du monde extérieur (ceci est particulièrement ensible en cas d'application accessible sur internet). Aussi, nous partons toujours du principe que les dernières versions du logiciel sont installées.

 

Etablir un diagnostic - apporter un correctif

 

Obtenir de bonnes performances avec des volumes de données importants nécessite une bonne réactivité d'un bout à l'autre de la chaine des traitement, que ce soit pour le serveur http ou pour le poste client.

 

La machine serveur

 

Mémoire vive disponible (8 Go recommandé), nombre de coeurs (le plus est le mieux / un seul est pénalisant), niveau de remplissage du disque (suivant les recommandations : jamais plus de 90 %), sa technologie (SSD pour l'application et les données, disque dur pour les archives).

 

L'application Kentika server

 

Kentika doit disposer de suffisament de mémoire vive. 4D Server ne doit jamais prendre sa mémoire cache dans la mémoire cache de windows.

 

Dans l'exemple ci-dessus, Kentika server exploite au mieux la mémoire disponible sur le serveur, sans avoir recours au cache de windows et en ayant suffisamment de mémoire pour chager le maximum de données et d'index : les performances seront ici optimales.

 

Le serveur 4D est dimensionné pour traiter des volumes de données et des nombres d'utilisateurs simultanés très largement supérieurs à ceux mis en jeu dans les bases Kentika. La mémoire affectée à Kentika doit cependant être cohérente avec les données à traiter.

 

Si besoin, ajuster les paramètres "Taille minimale / maximale" tenant compte de la mémoire disponible.

 

Le fichier de données

 

Au fil des mises à jours du contenu (ajouts, modifications, suppressions mais aussi consultations qui génèrent des écritures au log), le fichiers de données voit ses performances se dégrader. Pour résoudre ce problème, il est nécessaire de restructurer régulièrement sa base de données.

 

Pour cela deux méthodes sont possibles :

- le compactage proposé par 4D Server ;

- créer un fichier de sauvegarde / régénérer le fichier de données via Kentika.

 

Le compactage proposé par 4D Server est  exécuté directement sur le serveur. Après exécution, l'application ouvre automatiquement avec le nouveau fichier.

 

Restructuration via les outils de Kentika

 

Deuxième méthode : utiliser les outils de Kentika. Nécessite plus de manipulations et de connaissance du logiciel mais le fichier produit est beaucoup plus performant car, si 4D optimise le fichier de données, Kentika optimise l'ordre des tables et des enregistrements.

Les opérations sont les suivantes :

- quitter Kentika server ;

- lancer Kentika Monoposte et sélectionner le fichier de données ;

- s'identifier puis dans le menu Fichier/Exploitation/A : sélectionner "Créer un fichier de sauvegarde" ;

- enregistrer le fichier (par exemple : "RecordsKentika.txt" dans le répertoire "Kentika/Backup") ;

- quitter Kentika Monoposte ;

- procéder à une copie de sauvegarde du fichier de données (...4DD) ;

- relancer Kentika Monoposte en maintenant la touche Alt enfoncée ;

- Choisir le nom du fichier de données, son emplacement devra être dans le répertoire Kentika/Data ;

- à l'ouverture, il est demandé de sélectionner un fichier de sauvegarde :

- Sélectionner le fichier (RecordsKentika.txt dans l'exemple ci-dessus), la réintégration se déroule (cette opération peut prendre entre quelques minutes et une heure) ;

 

Nouveau nom du fichier de données : il est préférable de conserver le même nom, cela permet au programme de sauvegarde intégré de poursuivre l'incrémental qui utilise le nom du fichier de données. Si l'on a un doute, on le génère avec un autre nom pour le distinguer de l'original et l'on adapte la paramétrage en conséquence.

 

- Effectuer quelques vérifications de bon fonctionnement avec la version monoposte ;

- Quitter Kentika monoposte ;

- Isoler l'ancien fichier de données (s'il n'a pas été remplacé lors de la réintégration du fichier de sauvegarde) ;

- Lancer Kentika server en maintenant la touche Alt enfoncée afin de s'asssurer que le bon fichier de données est ouvert ;

- Procéder au reparamétrage de la sauvegarde ;

- S'assurer du bon fonctionnement ;

- Quitter l'application Kentika Server ;

- Relancer le service Kentika Server ;

- Procéder à des vérifications ;

- Les utilisateurs peuvent se reconnecter et poursuivre leur exploitation.

 

Le contenu des données

 

De manière générale, tout volume de données a un impact potentiel négatif sur les performances. On veillera donc à ne pas conserver des données devenues inutiles dans sa base de données. Ceci concerne particulièrement les logs et les emails.

 

Surveiller la table des logs : les logs de Kentika constituent une information précieuse pour comprendre l'activité de sa base base de données. Ils peuvent cependant devenir très volumineux et il convient d'intervenir.

 

Si la table personnes (utilisateurs) est synchonisée avec un annuaire d'entreprise chaque nuit, chaque mise à jour provoquera une écriture dans la table des logs. Pour 5 000 personnes, cela représenterait 1.8 millions d'écritures.

 

Lors de l'écriture d'un nouvel enregistrement dans la table "Log", 4D server doit mettre à jour les index de la table et ceci sera d'autant plus long que les index sont volumineux.

 

La table log a un double objectif : expliquer des mises à jour, voire des suppression, en fournissant l'identifiant de la personne à l'origine de l'action et les dates et heures de l'opération. Le deuxième concerne les statistiques et tableaux de bord.

 

Un objectif situé entre 200 000 et 350 000 lignes dans la table log correspond à la grande majorité des cas de figure.

 

Trois méthodes de purge de la table des logs sont proposés.

 

Méthode détaillée avec sauvegarde

Via "Fichier/Exploitation/A/Gestion des logs et statisqtiques", le dialogue propose

Dans l'exemple ci-dessus, en cliquant sur "Log -> Archive" on supprimerait de la base de données 48963 logs correspondant à des actions antérieures au 2/8/2016. Le fichier se sauvegarde est créé sur le disque de l'utilisateur dans son répertoire "AKTemp/(signature de la base)_C/ArchiveLOG"

 

Méthode rapide avec sauvegarde, sans choix affiné par l'utilisateur

 

En bas à droite du dialogue "Fichier/Préférences/Base/Paramétrage" figurent le nombre de logs et un bouton en forme de poubelle.

En cliquant sur ce bouton, Kentika effectue une sélection de logs sur la base de critères prédéfinis, génère un fichier de sauvegarde dans le répertoire ArchiveLOG (idem ci-dessous) et supprime les logs.

Critères de sélection

- Les logs des enregistrements supprimés depuis plus de 60 jours ;

- Les logs des tables de paramétrage de plus de 30 jours ;

- Les logs de consultation et de mise à jour de plus de 365 jours (ce délai peut être modifié en maintenant la touche majuscule enfoncée après avoir validé le dialogue "Clear time out log ?" et en indiquant un nouveau délai dans le dialogue proposé)

- Les logs de recherche ou de consultation de dossier de plus de deux fois le délai (par défaut : 2 ans) ;

- Les logs de synchros de plus de 90 jours ;

- Les exécution de scripts ou de maquette de plus de 365 jours (cf ci-dessus).

Cette opération peut être automatisée pour s'exécuter en mode batch sur le serveur (procédure à appeler dans le script : "Log_Delete")

 

Méthode sélective sans sauvegarde

 

Depuis la table des logs (Fichier/Exploitation/C/Display_Log), effectuer les sélections à l'aide des outils génériques proposés en haut à droite de la liste.

Cette méthode nécessite de bonnes connaissances des outils de manipulation des données sans qu'aucun contrôle ne soit effectué.

 

Après une suppression massive, il est recommandé de procédé un compactage ou une restructuration de la base de données (cf ci-dessus).

 

Le serveur HTTP

 

Ouvert sur l'extérieur, le serveur http constitue un goulot d'étrangelemnt potentiel. Une attention toute particulière doit être portée à son paramétrage.

 

Règles de base à respecter

- Choisir une machine avec plusieurs coeurs (2 minimum) pour bénéficier du multithreading ;

- Déclarer, dans "Fichier/Préférences/Serveur web/Paramètres de connection/GE-SSO-LDAP" Serveur http : "$webfolder" ou "$webfolder/(dossier ged)" ou  "dossier ged" désigne un sous répertoire (exemple : $webfolder/GED_KENTIKA) ;

- Se définir une stratégie par rapport aux robots d'indexation (se contenter de les identifier ou bien les refuser) ;

- Surveiller régulièrement l'activité du serveur ;

- Utiliser la page "areuthere.htm" ou "4DWEBTEST" pour surveiller le bon fonctionnement de son site ;

- Paramétrer un "email - supervisor" afin d'être prévenu si le nombre d'invités atteint un niveau anormalement élevé (rappel : les robots ne renvoyant jamais les cookies, un nouvel utilisateur temporaire est créé à chaque requête).

 

Stratégie par rapport aux robots

Bien gérer les robots nécessite de bien comprendre comment ces derniers fonctionnement et de savoir ce que l'on est prêt à partager avec eux.

Distinguer un "vrai robot" d'un "faux robot" : un vrai est (relativement) honnête et demande regulièrement la page Robots.txt pour savoir ce qu'il est autorisé à demander. Au passage, il peut identifié comme tel.

 

Dans Kentika : Préférences/Serveur web/Paramètres de connexion/Filtre

 

Le nombre de robots ainsi identifiés peut facilement atteindre plusieurs milliers. Il est recommandé de procéder à des regroupement en utilisant la notation @. Dans l'exemple ci-dessus, toutes les adresses commençant par 66.249. (google) seront identifiées comme des robots.

 

Un faux robot ne demande jamais la page "Robots.txt", ne renvoit aucun cookie et travaille sur une plage de temps restreinte (quelques jours en général). Il existe des robots qui "aspirent" le contenu de sites et ceux qui tentent de prendre le contrôle de la machine en exploitant les failles connues de certains serveurs http. Kentika est "insensible" à ce type d'attaque. C'est donc principalement les "aspirateurs de contenu" qu'il convient de surveiller.