Installation : choix du matériel

Plusieurs facteurs influent sur le comportement de l'application, il convient de les prendre en compte avant de choisir le matériel qui vous offrira un bon confort d'utilisation.

Le choix d'une configuration est toujours un compromis performance / investissement. Il y a cependant des seuils en dessous desquels votre application aura des difficultés à fonctionner (exemple : insuffisance de mémoire vive, disque dur saturé). Vous trouverez ci-après des conseils pour vous situer au-dessus de ces seuils et d'obtenir un bon confort d'utilisation.

Systèmes d'exploitation compatibles

Windows : windows 7, 8 ou 10. Pour un serveur, il est conseillé (mais non imposé) d'opter pour un système serveur (exemple : Windows 2012 Server R2).

Kentika 4 exploite la version 18 de 4D, vérifier la matrice de compatibilité de l'éditeur 4D SAS.

Pour en savoir plus : cliquer ici.

Suivant la configuration en place, Kentika peut exploiter d'autres fonctions (ie : autre que 4D), les OS compatibles sont :

• Kentika Document Engine (KDE): Serveur Windows uniquement, client Mac ou Windows
• PDF Review : windows uniquement, ne concerne que les postes client
• Abby Finereader en mode post-archivage : windows uniquement

Macintosh : à partir de Mac OS 10.9.5. Processeurs Intel exclusivement à partir de Kentika 2.

Kentika et VMWare

Il n'est pas obligatoire d'avoir un serveur dédié. Une configuration VMWARE permet de réadapter la configuration de la machine en fonction de la montée en charge du service installé et d'éviter les effets de bords entre les différents logiciels.

Technologie et traitement complémentaire

Revue de presse

Si les articles sont numérisés et enregistrés en pdf, plusieurs aspects sont à prendre en compte : le mode d'acquisition, l'optimisation et la reconnaissance optique de caractères. Un fichier pdf issu directement d'un scanner avec des images en couleur va avoir une taille moyenne de 1Mo. Le même fichier optimisé et traité en OCR verra sa taille réduite à 50 Ko. Pour optimiser un fichier : un supplément de capacité de calcul sera demandé au poste de travail. Par contre, le réseau sera ensuite beaucoup moins sollicité.

Indexation texte intégral

Cette dernière s'effectue via des technologies tierces. Elle est exécutée au niveau du serveur : un surplus de capacité sera donc nécessaire sur le serveur si une telle technologie est utilisée.

Taille des index liés aux fichiers GED, impact sur l'occupation sur disque : un coefficient moyen de l'ordre de 30 % est à prévoir. Ce chiffre dépend en fait de la proportion de texte par rapport aux images de vos documents GED.

Ainsi, si vous prévoyez une taille de GED de 500 Mo, avec les index, il faudra compter : 500 * 1,3 soit 650 Mo.

Serveur d'archives

Dans une architecture orientée GED, deux fonctions serveurs seront mises en oeuvre : le serveur de données et le serveur de documents. Deux architectures sont possibles :

- Kentika assure l'accès aux méta-données et aux documents ;

- Kentika assure l'accès aux méta-données et le service des documents est assuré par un autre serveur (ex : IIS).

Si les fichiers sont nombreux, volumineux ou avec un fort trafic, la deuxième solution sera à privilégier.

Envoi de emails

Le protocole d'envoi est le smtp. Pour réaliser la diffusion sélective d'informations, les relances d'emprunts ou les communications ponctuelles, un serveur smtp devra être accessible (au moins à partir du poste serveur).

Choix du disque dur

Une base de données implique un nombre d'accès au disque dur important. Ce dernier devra être choisi avec attention. En effet, deux facteurs sont importants : la vitesse et le taux de remplissage. Ce dernier facteur influe sur le taux de fragmentation. Plus un fichier est fragmenté et plus on provoque de déplacements de la tête de lecture, d'où un ralentissement. En ne dépassant pas les 50% de taux de remplissage, on s'assure un fonctionnement correct.

NB : un disque dur rapide peut être parfois un investissement plus profitable qu'un processeur rapide.

Au niveau d'un poste client, la vitesse du disque dur est moins déterminante car ce dernier n'accueille pas vos données.

Disque SSD

Les performances de toute application en générale et d'une base de données en particulier sont toujours supérieures avec un disque SSD. Il est possible d'avoir :

- OS + Application Kentika + fichier de données : sur disque SSD ;

- fichiers GED : sur disque dur classique.

Gain de performance sur une opération de tri utilisant une formule sur une base contenant 200 000 notices : 30% de temps en moins avec un disque SSD.

Choix de la mémoire vive

Au niveau d'un poste client, l'application occupe environ 100 Mo de mémoire vive.

Au niveau d'une application monoposte ou serveur, cela dépend en partie de la base de données, et en partie de la taille des fichiers de GED qui peuvent être transférés.

500 Mo ou 8Go de mémoire vive ? tout dépend du nombre d'applications fonctionnant simultanément. Sur un poste client, il sera courant d'avoir un navigateur, un logiciel de messagerie, Acrobat, un traitement de texte, Kentika Client. Il faut donc prendre en compte que la mémoire vive se répartit entre toutes ces applications.

En serveur ou en monoposte, Kentika a en charge la gestion des données. Afin d'éviter d'incessants accès au disque dur, les données sont gérées en cache (dans la mémoire vive de l'ordinateur). Il faut absolument éviter que le cache de l'application soit en fait géré dans le cache de windows (ce qui provoque un effondrement des temps de réponse). Une règle simple à appliquer : avoir une mémoire disponible égale à la taille du fichier de données (.4DD).

Note : Les systèmes d'exploitation récents demandent au moins 2 Go de libre pour fonctionner. Il faut donc ajouter la mémoire nécessaire pour Kentika à celle nécessaire pour l'OS.

Mémoire minimum : 4Go, recommandée : 8Go.

Processeur

La vitesse d'horloge de votre ordinateur est un facteur important. Elle doit cependant être cohérente avec l'ensemble de votre installation. Une machine architecturée pour fonctionner comme serveur offrira une meilleure gestion des entrées-sorties et donc de meilleures performances.

Notez que depuis la v3, Kentika commence à tirer partie du multi-threading. Prévoir plusieurs processeurs sur un serveur peut donc améliorer significativement les performances, en particulier en cas de multiple accès Web.

Conseils pratiques

Entretien de son ordinateur

Votre installation va vivre et les performances vont (presque) mécaniquement se dégrader. Il convient régulièrement de vérifier la fragmentation des disques, vider des dossiers temporaires, utiliser des outils de "nettoyage".

Instabilité

Une erreur hardware peut provoquer des instabilités dans une application. Très difficiles à détecter et à diagnostiquer, ces erreurs peuvent laisser croire que l'application présente un bug. Pour éliminer cette hypothèse : faire préalablement un test avec une autre machine.

Entretien de la base de données

Un fichier de données évolue en permanence. Il convient de s'assurer régulièrement qu'il ne comporte pas d'erreurs qui peuvent provoquer des instabilités voir rendre la base inutilisable si l'on attend trop longtemps. Dès que Kentika présente des arrêts intempestifs, il convient de vérifier l'état des données avec le "centre de maintenance".

Journal des logs : Kentika enregistre beaucoup d'opérations dans le log. Si l'on n'y prend pas garde, la table des logs va grossir de manière importante et provoquer une dégradation des performances. Il convient de s'assurer que les règles d'archivage des logs soient bien fixées.

Optimisation : l'opération consistant à créer un fichier de sauvegarde puis à le réintégrer dans une base vide est un moyen efficace pour optimiser le fonctionnement de sa base de données. En effet, les enregistrements sont exportés puis ré-importés dans un certain ordre assurant ainsi une bonne performance dans les accès.