Règles de bonne exploitation de Kentika Server

Cette fiche récapitule les règles de bonne installation, de bonne exploitation et fournit un ensemble de points de repère pour la résolution de problèmes de performance.

1 - Les composants matériel

2 - Les composants de Kentika Server

3 - Les réglages de Kentika Server

1 - Les composants matériel à considérer

L'application Kentika server fonctionne sur une machine et évolue dans un environnement qui, si l'on n'y prend pas garde, peuvent influer de manière significativement négative sur les performances.

Dans l'énoncé ci-dessous, chaque composant est évalué avec un facteur de risque sur une échelle de 1 (rare et peu d'impact) à 5 (à surveiller avec attention). Ne sont pas repris les pré-requis d'installation, partant du principe que Kentika a été correctement installé et que le fonctionnement était correct lors du lancement.

Au niveau du serveur Kentika

Un ordinateur

Réel ou virtuel : les performances seront comparables. Dans de très rares cas, des défaillances du hardware (exemple : une carte réseau défectueuse) peuvent entraîner des instabilités. Si un autre programme fonctionne en même temps sur le serveur, on s'assurera qu'il n'y a pas de conflit possible avec Kentika.

Niveau de risque : 1

Il est toujours recommandé de se référer à la matrice de certification publiée par 4D : pour la version 19.7 (celle de Kentika 4.5)  https://fr.4d.com/resources/4d-19-lts

Un système d'exploitation

Dès lors qu'il est compatible avec la version de 4D serveur, il n'est en général pas source de problème.

Niveau de risque : 1

Antivirus

Bien qu'il n'y ait pas de contre-indication à l'utilisation d'antivirus avec Kentika, en fonction de l'intrusivité de l'antivirus, des exceptions peuvent devoir être ajoutées. En effet, si l'antivirus (ou retarde) l'accès à certains fichiers, cela peut fortement ralentir l'application, voire provoquer des messages d'erreur.

Dans ce cas, il peut falloir désactiver la surveillance en temps réel sur certains dossiers liés au logiciel (serveur ou client) :

• AKTemp : C'est celui qui peut avoir le plus d'impact sur le logiciel. Kentika lit et écrit en permanence dans ce dossier. Des blocages sur son contenu provoquent de grosses lenteurs et de nombreux messages d'erreur. Bien que ce dossier réceptionne initialement tous les fichiers envoyés depuis le client Web, il a un risque limité, parce-que ces fichiers ne sont pas directement accessibles par le portail Web. Désactiver la surveillance en temps réel n'est donc pas dangereux.
• ALGEDIM (serveur uniquement) : Ce dossier contient tous les fichiers stockés dans la BDD. Une exception de l'antivirus y est moins souvent nécessaire, tant qu'il ne bloque pas les manip du logiciel sur ces fichiers. D'autre part, ces fichiers sont ensuite accessibles aux utilisateurs finaux, donc un fichier qui y serait vérolé, s'il a peu de chance de poser un risque pour le serveur, peut poser des risques pour d'autres utilisateurs qui les récupérerait ensuite.
• Webfolder (serveur uniquement) : Là aussi, une exception est moins souvent nécessaire. Les fichiers sont rarement écrits (mais souvent lus), et sont accessibles aux utilisateurs finaux.
• Dossier de l'application : Difficile de déterminer l'impact global d'une exception sur l'appli elle-même. L'appli doit pouvoir modifier son propre dossier, mais cela arrive plus rarement (en particulier pour le serveur). Une exception peut être ajoutée sur l'application elle-même si des erreurs inexpliquées se produisent souvent, et que les exceptions sur les autres dossiers mentionnés ici ne résout pas la situation.

Dans tous les cas, même si la surveillance en temps réel est désactivée pour un ou plusieurs dossiers de l'application, il est absolument indispensable de conserver des scans réguliers sur ces dossiers, en faisant attention à ce que des fichiers essentiels ne soient pas supprimés...

Niveau de risque : 3

Mémoire vive

Les facteurs à prendre en compte pour déterminer la mémoire vive optimale sont

• taille du fichier de données ;
• nombre d'utilisateurs simultanés ;
• nombre de visiteurs http moyen par jour ;
• volume d'activité au niveau de la GED ;
• utilisation de KDE (Kentika Document Engine) ;
• version de Kentika.

La machine serveur devrait disposer, pour l'exploitation d'une base moyenne (100 000 notices), de 8 Go. Avec une activité web/ged soutenue : 16 Go donnera de meilleures performances.

Une mémoire trop limitée peut générer un effondrement des performances (si le cache de 4D se fait dans le cache de Windows).

NB : le volume global des archives n'a pas un impact significatif sur les besoins en mémoire vive.

Niveau de risque : 5

Fréquence du problème : moyenne

Vitesse d'horloge

Plus la vitesse d'horloge est élevée, meilleures sont les performances. Elle n'est cependant jamais une raison de dégradation des performances.

Niveau de risque : 2

Nombre de cœurs

La base de données Kentika fonctionne, depuis la version 4.5, sur l'ensemble des cœurs (multithread). Les requêtes web correspondant à des fichiers se trouvant dans le dossier racine (webfolder) peuvent être traitées par l'ensemble des cœurs. Aussi, dès lors que le serveur http a une activité soutenue, plus il y a de cœurs et plus rapides seront les accès. Ceci est particulièrement vrai si l'activité web/ged est soutenue.

Niveau de risque : 3

Support de stockage

Trois points critiques sont à considérer : la technologie, la vitesse de rotation (pour les disques durs), le niveau de remplissage. Nous prenons ici pour acquis que le volume hébergeant l'application et la base de données n'est pas un volume réseau (qui peut présenter des temps de réponse catastrophiques).

Un disque SSD sera préféré pour les programmes et le fichier de données. Un disque dur pour les sauvegardes et les archives.

Taux de remplissage : s'il est trop élevé, il entraîne des fragmentations des fichiers et peut provoquer une perte significative de performance, voire une incapacité du programme à fonctionner.

Niveau de risque : 4

Configuration client/serveur

Lorsqu'un Kentika Client se connecte à un Kentika Server, il y a un réseau qui leur permet de dialoguer.

Si le serveur est correctement configuré et que le client ne présente pas d'anomalie de fonctionnement, le réseau peut être un facteur de dégradation.

Le poste client

Les points à considérer au niveau du client sont :

• vitesse d'horloge ;
• qualité des disques ;
• mémoire vive ;
• nombre d'applications lancées simultanément.

Le client ne stockant pas les données de la base, il est, en général, moins sensible aux volumes et à l'activité.

Comme pour le serveur, l'antivirus peut être un facteur d'instabilité, voire de perte de performance.

Niveau de risque : 2

Le réseau

Il est important de savoir si la liaison entre le client et le serveur s'effectue via un réseau local ou bien si des connexions externes (internet par exemple) sont mises en jeu. Des systèmes de surveillance au niveau du réseau peuvent aussi, par une analyse très intrusive, ralentir fortement le dialogue entre les clients et le serveur.

Niveau de risque : 3

Mon installation est-elle performante ?

Lorsque l'on est confronté à un problème de performance, il est souhaitable, dans un premier temps de s'assurer que son installation offre un bon niveau de qualité. Pour cela, il suffit d'effectuer un test en éliminant toute spécificité liée à son installation.

Kentika vous permet de créer un environnement de test avec "serveur / base de démo / client". Si les performances sont éloignées de celles constatées en "usine", c'est sur un des composants décrit ci-dessus que doit se porter l'attention.

2 - Les composants de Kentika Server

Arborescence recommandée

L'installation, si elle a été réalisée suivant les règles, et la mise en service de Kentika ont dû aboutir à ce qui est décrit ci-après. Cette organisation est recommandée afin que l'on puisse intervenir sans méprise sur l'installation si le besoin est exprimé.

Codes couleur

En vert  : ce qui est créé automatiquement

En bleu  : ce qui constitue votre application spécifique

En rouge  : le générique Kentika

En magenta  : ce qui est généré par l'installeur de KDE (si cette option fait partie de votre installation)

Les noms de dossiers comportant "MABASE " doivent être interprétés en remplaçant "MABASE" par la signature de votre base de données.

Depuis la racine du disque (C en général)

• AKTEMP
  • MABASE_S
  • ACROTEMP
• ALGEDIM
  • MABASE
  • MABASE_T
  • MABASE_Tx
  • MABASE_PDF
  • luceneindex
• Kentika
  • Data
    • Kentika_(mon site).4DD
    • Kentika_(mon site).indx
    • Kentika_(mon site).Match
  • Programme
    • KentikaMono
    • KentikaServer
    • KentikaClient
    • Lucene REST Services for Kentika
  • Backup
    • Kentika_MABASE.journal
    • Kentika_MABASE[nnn].4BK
    • Kentika_MABASE[nnn].4BL
  • Tools
    • (installeurs)
• WEBFOLDER
  • ckeditor ; kent-font …
  • kent-css (créé lors du lancement)
  • GED_MABASE (créé lors du chargement de fichier ged)

​

Anomalies possibles

Avant d'envisager les actions dans l'application Kentika Server et les réglages dans Kentika Client, portons une attention aux contenus des répertoires.

Toute intervention évoquée ci-après s'entend Kentika Server arrêté. Si vous suprimez des fichiers alors que le serveur fonctionne, des risques d'instabilité sont encourrus.

AKTEMP\MABASE_S

Ce répertoire est quasi-temporaire : il est reconstruit lors du lancement.

Il se peut qu'un fichier soit endommagé et empêche le serveur de démarrer ou un client de se connecter.

Solution : supprimer les dossiers "Temp" ; "WEBPOST" ; "TableAutorize" ; "Folders" ; "WEBTEMP" ; "TempList" ; "KV_Temp" ; "FTP_Temp"

Niveau de risque : 2

Fréquence du problème : rare

Le répertoire "WEBLOG" contient les journaux des requêtes traitées par Kentika. Ce répertoire WEBLOG n'est pas vidé par Kentika : cela doit être fait manuellement si l'on n'a plus besoin des fichiers en historique afin d'éviter un accroissement du nombre de fichiers inutiles.

Niveau de risque : 2

Fréquence du problème : rare

​

AKTEMP\MABASE_S\LOGTRACE

Ce répertoire permet d'écrire un journal quotidien où sont consignés un certain nombre d'évènements. Il doit être créé manuellement, généralement sur demande de l'équipe support. Lorsque il n'y a plus de nécessité d'observer les évènements, il conseillé de le désactiver : pour cela, il suffit d'en changer le nom (exemple : LOGTRACE_). En effet, comme tout écriture sur le disque, cela prend du temps et de l'espace disque.

AKTEMP\MABASE_S\WEBDBG

Dans ce répertoire, s'il existe, sont écrites les URL avant début de traitement ; elles sont supprimées si la page html correspondante a été calculée intégralement. Les consignes mentionnées pour LOGTRACE s'appliquent aussi à ce répertoire.

AKTEMP\ACROTEMP

Ce répertoire est utilisé lorsqu'un traitement OCR s'effectue en tâche de fond. Vérifier régulièrement le contenu de ce répertoire permet de constater si tout se déroule correctement.

Erreur parfois rencontrée : l'option "Traitement en tâche de fond" a été sélectionnée en "Préférence/Paramétrage/Archivage" alors qu'il n'y a pas d'OCR opérationnelle sur le serveur. Le répertoire se remplit alors de copies des pdf qui ne seront jamais océrisés.

Niveau de risque : 1

Fréquence du problème : rare

​

ALGEDIM

Ce répertoire comporte les fichiers primaires, leurs déclinaisons ainsi que l'ensemble des index pour les recherches Full Text.

ALGEDIM\MABASE\D..

Contient les documents primaires. Ce sont les documents les plus importants des dossiers ALGEDIM et il est impératif qu'ils soient sauvegardés régulièrement (hors solution de Kentika Server évoquée ci-après).

Les autres dossiers décrits ci-dessous peuvent être recalculés à partir des documents primaires.

ALGEDIM\MABASE\P..

Contient les prévisualisations, pour les document bureautiques ou pdf : la première page. Sont calculés par Kentika Server à partir des documents primaires (pour les images ou les pdf) ou à partir des pdf calculés dans le cas de documents bureautiques.

ALGEDIM\MABASE\E..

Contient les images basse résolution des documents image (exemple : les .jpg, les .png).

ALGEDIM, si KDE est installé

ALGEDIM\MABASE\M..

Contient des textes, issus des méta-données des notices, à indexer afin que les recherches full text puissent porter de manière homogène à la fois sur les méta-données et les textes primaires.

ALGEDIM\MABASE_T\D..

Textes issus des documents primaires. Utilisés lorsque l'on veut présenter un mot dans son contexte à l'issue d'une recherche full text.

ALGEDIM\MABASE_Tx\D..

Textes utilisés par le moteur d'indexation full text. (obsolète depuis KDE2)

ALGEDIM\MABASE_PDF\D..

Contient les documents bureautiques convertis en pdf.

ALGEDIM\luceneindex(2 ou 3)\MABASE

Contient les index du full text.

Pour simplifier une opération éventuelle de reprise : il est fortement conseillé de sauvegarder l'intégralité du répertoire ALGEDIM sur un support physique autre que le disque du serveur.

Kentika\Data

Dans ce répertoire se trouve le fichier le plus précieux (avec ALGEDIM) de toute l'installation : celui dont le suffixe est .4DD

Il est fortement recommandé qu'à tout instant, il n'existe qu'un et un seul fichier de données ayant pour extension .4DD sur le disque. Si l'on doit en avoir une copie : la compresser pour éviter toute ouverture avec Kentika Server.

Niveau de risque : 4

Fréquence du problème : moyen

NB : souvent lorsque l'on ne retrouve pas les données saisies sur une période, c'est parce qu'il y a eu confusion sur le fichier de données ouvert.

Le fichier de données comporte les données, le fichier d'index, calculé à partir des données et de ce qui est déclaré dans la structure même de Kentika, est indépendant. Il porte le même nom que le fichier de données, est placé dans le même répertoire et a pour extension .4DIndx.

Il arrive que les index soient endommagés. Même si cela est rare, une solution simple pour résoudre ce problème consiste à arrêter Kentika Server, renommer le fichier ayant .4DIndx pour extension et relancer Kentika Server : le fichier est alors reconstruit.

Kentika\Programme

Les trois applications installées doivent être en phase au niveau des versions. Il est conseillé de supprimer, a minima d'isoler, les versions antérieures.

Ne pas lancer le monoposte lorsque Kentika Server est en cours d'éxécution. Ne pas lancer l'application Kentika Server lorsque le service Kentika est en cours.

Niveau de risque : 2

Fréquence du problème : élevé

Il est arrivé que les composants du programme ait subi une dégradation empéchant Kentika Server de s'éxécuter. Dans ce cas, il suffit de remplacer simplement le contenu du dossier en reprenant l'installeur d'orgine.

Niveau de risque : 1

Fréquence du problème : très rare

Kentika Client sur le serveur

Cette solution doit être réservée à des réglages ponctuels. Il se peut que le client soit très lent (problème de communication entre le serveur et le client), dans ce cas, il est conseillé de se connecter à partir d'un autre poste et de supprimer le répertoire Kentika\Programme\Kentika_client

Kentika\Backup ou Kentika\Sauvegarde

Ce répertoire (créé manuellement et désigné dans les réglages du serveur) contient : le .journal, les sauvegardes intégrales de la base de données et les sauvegardes des journaux.

Il est important de s'assurer régulièrement que les sauvegardes s'effectuent correctement. Depuis la version 3, si le "email-supervisor" est renseigné, un email avertit si la sauvegarde n'est pas effectuée ou s'il le journal n'est pas généré.

Lors d'un changement de version, de changement de nom du fichier de données, il se peut que la sauvegarde n'ait pas été correctement reprogrammée. Il convient d'être très vigilant sur ce point.

Niveau de risque : 5

Fréquence du problème : moyen

Ces sauvegardes sont la garantie de pouvoir redémarrer en cas de problème, même physique, aussi il est impératif qu'elles soient sauvegardées régulièrement.

Tools

Utiliser ce répertoire pour y copier, temporairement, les derniers installeurs utilisés. Il est conseiller de ne pas conserver les versions antérieures afin d'éviter des "mélanges de versions".

Niveau de risque : 4

Fréquence du problème : rare

Programme\Kentika

Ceci fait partie de KDE, dont la version doit être en phase avec celle de Kentika. Aussi, si dans les procédures d'installation d'une nouvelle version il est indiqué que KDE doit être mis à jour, il sera nécessaire de le désinstaller via les outils windows puis de réinstaller l'installeur fourni par Kentika.

L'application KDE intervient sur des fichiers dont il est difficile de s'assurer qu'ils soient conformes au format qu'ils sont supposés respecter. Dans ce cas, il peut arriver que KDE ait besoin d'être redémarré (ce cas peut arriver principalement lors de l'extraction initiale du stock de textes).

Niveau de risque : 2

Fréquence du problème : rare

WEBFOLDER

Le serveur http de Kentika Server fonctionne en double détente. Lorsqu'une requête arrive au serveur, soit elle correspond à un fichier se trouvant dans le répertoire racine "webfolder" : le fichier est alors directement envoyé par 4D Server ; soit la requête ne correspond pas à un tel fichier auquel cas elle est prise en compte par la programmation de Kentika.

Un fichier envoyé directement par 4D Server (ie : un fichier se trouvant dans le répertoire webfolder) sera envoyé beaucoup plus rapidement que s'il est pris en charge par Kentika. De plus, 4D serveur tire profit des différents coeurs dont dispose la machine.

WEBFOLDER et la GED

L'optimisation de la transmission des fichiers GED passe par le fait d'utiliser le répertoire webfolder pour le transfert physique. De la version 2.4 à la version3, il était recommandé d'utiliser cette option. Pour cela, aller dans "Préférences/Serveur Web/Paramètres de connexion" onglet "GED-SSO-LDAP" et indiquez dans "Serveur http" : $webfolder" éventuellement suivi d'un nom de répertoire que vous spécifiez librement (choisir un nom simple, sans espace ni ponctuation, exemple : $webfolder/GED_MABASE).

Depuis la version 3, ce répertoire contient également des copies des previews, des images basses et des conversions en html (si KDE est installé).

Le "Nbre de jours" doit être réglé en cohérence avec la nature de la partie du fonds la plus consultée. Délai court si la presse constitue un volume important de consultation, un délai long pour des documents de réferences. Si la base contient un nombre significatif de documents confidentiels, un délai court sera préféré. En effet, il y a un double mécanisme de sécurité lorsqu'un utilisateur appelle une notice : Kentika ne calcule l'URL de la pièce jointe que si l'utilisateur y a droit, une nouvelle vérification est effectuée lorsque l'URL correspondant est activée. Avec cette méthode optimisée, seule le première vérification est effectuée.

WEBFOLDER et les CSS

Avec Atomic, toutes les css sont précalculées et stockées dans ce répertoire, à raison d'un jeu par espace. Dès qu'un paramètre est changé dans les templates ou dans les attributs (couleur et bandeau d'entête), les css sont recalculées.

WEBFOLDER les Javascript

De même que pour les .css, les .js sont également précalculés et stockés dans le répertoire webfolder\kent-js\custom\(3 premières lettres de la signature).

Déclaration du répertoire racine "webfolder"

Compte tenu de ce que répertoire est partagé entre 4D Server et Kentika server, il est impératif que le même répertoire soit déclaré comme racine au niveau du serveur et au niveau de Kentika.

Niveau de risque : 3

Fréquence du problème : rare

​

​

3 - Les réglages de Kentika Server

Ce qui suit pré-suppose que tout ce qui est décrit ci-dessus a été pris en compte. Nous considérons donc ici une installation réalisée dans les "règles de l'art" sur une machine apte à fournir de bonnes performances.

Les réglages sont à refixer, a minima à vérifier, lors de chaque changement de version de Kentika.

Avant le lancement de l'application, il est nécessaire de s'assurer que le pare-feu ne bloquera pas l'accès au serveur.

Le système d'auto-surveillance

Kentika dispose d'un système permettant d'alerter l'administrateur lorsqu'une anomalie est détectée dans l'exploitation de la base de données.

Son activation est simple : il suffit de renseigner dans "Préférences/Base/Pramétrage/Exploitation" l'adresse email du supervisor. A minuit, Kentika effectue des vérifications et adresse un email si un des éléments décrits ci-dessous mérite attention.

​

Paramètres surveillés

• Existence d'un fichier d'historique.
• Date de dernière sauvegarde : doit dater d'un jour au plus.
• Nombre d'enregistrements de la table log si celui-ci est supérieur à une valeur calculée comme suit :
  • nombre d'enregistrements dans les tables document + auteur + personne + revue + référence + thesaurus augmenté de 200 000 (cette valeur peut être ajustée via le paramètre "X_ML").
• Nombre de mails antérieurs à la date du jour non envoyés.
• Nombre de dossiers dans le répertoire guest s'il est supérieur à 90.

Actions à entreprendre lors de la réception d'un message d'alerte.

• Si pas de fichier d'historique : vérifier les paramètres de sauvegarde du serveur.
• Dernière sauvegarde datant de plus de 24 h: idem.
• Log : vérifier quelles sont les requêtes qui font s'accroître de manière exessive le log. Une attention particulière doit être portée aux robots qui scrutent le site, aux programmes d'import qui provoquent des mises à jour récurrentes (exemple : mise à jour de la table des personnes). Si la situation est correcte, augmenter la valeur du paramètre "X_ML" afin de ne pas recevoir de emails répétitifs. NB : pour connaître le contenu de la table des log, activer l'option de menu "Fichier/Exploitation/Onglet C/Display_Log". Si une suppression massive de log est envisagée, il est conseillé d'utiliser l'option "Fichier/Exploitation/Onglet A/Gestion des logs et statistiques".
• emails non envoyés : cela peut résulter soit d'une adresse email incorrecte, soit d'un problème intermittent de communication avec le serveur SMTP.

Informations sur l'exploitation de la base de données

Des informations détaillées sur les conditions d'exploitation de la base de données peuvent être facilement obtenues via l'URL :

http://(adresse du serveur http)/GetExploitInfos.htm?exploitfrom=kentinfo

Identification : signature, version de Kentika, du kit Atomic. Technologie full text active (ISYS ou KDE)

Archives : volume, taille globale, nombre d'archives dont la taille est supérieure à 100 ko, vérification que toutes les archives soient bien déclarées sur le volume d'archivage.

Emails : nombre total (un nombre elevé de emails peuvent dégrader les performances, il est suggéré de supprimer les anciens emails), nombre de messages en erreur ou en attente.

Batch : les scripts programmés avec plage horaire et date / heure de dernière exécution.

Action : les scripts se déclenchant sur certains événements (une mauvaise affectation peut entrainer des problèmes graves d'exploitation).

Batch import : les paramétrages de la centrale d'importation.

Log : nombre total, ceux étant intervenus avant 7 h ou après 21 h (probablement, des robots d'indextion si leur nombre est élevé), ceux datant de plus de 3 ans (pouvant probablement être archivés).

Serveur http : taille et contenu du log de la veille. A regarder avec attention : les adresses IP des clients les plus actifs, si ce sont des robots d'indexation, les déclarer comme tel.

Memory : état de la mémoire vive de la machine. Permet de détecter les états critiques (mémoire libre proche de 0 ou sur-utilisation de mémoire cache).

Cache : état du cache du gestionnaire de données de 4D Server.

Fragmentation : exprimée en pourcentage, elle permet de déceler si un compactage serait à effectuer pour améliorer les performances.

Content : nombre d'enregistrements pour chacune des tables.

Surveiller le serveur http de Kentika server

Le serveur http de Kentika est généralement mis en surveillance par un automate qui l'interroge régulièrement afin de s'assurer qu'il réponde correctement. Une erreur fréquement commise consiste à appeler le serveur sans précision (exemple : http://monservice.net/). Kentika prépare alors, à chaque appel, un espace de travail pour le nouvel utilisateur, provoquant un encombrement dans le répertoire GUEST (cf : ci-dessus) et utilisant inutilement des ressources.

Il est fortement recommandé de faire "pointer" son automate sur l'URL suivante : http://(adresse du serveur http)/4DWEBTEST