1.3.5. PARTapplicationServer Installation/configuration 1.3.5.10. Plus d'informations |  |
| Précédent | Suivant |
Remarques sur la résilience et les performances/la mise en cache
Remarques sur les performances : 3 niveaux
En principe, PARTapplicationServer améliore les performances (recherche et navigation dans les index).
Si CADENAS_DATA se trouve sur un fichier supplémentaire, la mise en cache doit être activée pour le PARTapplicationServer. Voir à ce sujet Section 1.3.5.8.3.7, « Mettre en cache les fichiers d'index de $CADENAS_DATA sur PARTapplicationServer ».
Si le client a une mauvaise connexion réseau avec PARTapplicationServer, la mise en cache du client PARTdataManager doit être activée (Squid ou RFS). Voir Section 1.3.5.8.2.4, « Mise en cache côté client ou sur des sites secondaires ».
Stratégie de serveur de sauvegarde mise en place par CADENAS
Pour plus de détails, voir la Section 1.4.4.1, « Volet de dialogue "Serveurs connectés ».
Chien de garde Windows standard
Configurer PARTapplicationServer en tant que service présente l'avantage de le lancer automatiquement au démarrage de l'ordinateur serveur et d'utiliser les mécanismes de Windows pour surveiller la stabilité, comme par exemple le redémarrage en cas de crash (après une minute [peut être encore réduit par le registre]).
Voir à ce sujet le site Section 1.3.5.7, « Configurer PARTapplicationServer en tant que service ».
PLINKDB fonctionne généralement sur un serveur de base de données existant, dont la disponibilité est garantie par le client (stratégies spécifiques à la base de données).
Il existe plusieurs possibilités pour l'emplacement du répertoire de pool :
Placer le répertoire du pool sur le serveur, mais avec un partage différent de CADENAS_DATA
CADENAS_DATA=/server/share/data Répertoire du pool=/server/share2/data/pool
Placer CADENAS_DATA sur un répertoire fictif, le répertoire pool peut alors pointer sur le serveur.
CADENAS_DATA=c:/dummydir Répertoire du pool=/server/share/data/pool
Il est seulement important que le répertoire du pool ne se trouve pas sous CADENAS_DATA ; car c'est alors le RemoteFileSystem qui est responsable du répertoire du pool. Et ainsi, il est ReadOnly.
Les ports définis dans les fichiers de configuration pour le PARTapplicationServer et le serveur de recherche sont différents par défaut, ce qui permet de fonctionner en parallèle sur un serveur pendant la phase de conversion.
Ralentissement de la recherche lors de l'utilisation d'un disque dur virtuel
Lors du test sur une machine virtuelle, il faut tenir compte du fait que le disque C sur le serveur n'est pas vraiment local, mais se trouve sur le réseau. (Il se peut que la vitesse soit plus élevée avec un "vrai" disque C).
Si la mise en cache est utilisée, tous les index de recherche sont mis en cache sur le PARTapplicationServer. Cela est utile, car l'accès aux ressources locales est plus rapide.
Mais dans le cas d'une VM, il se passe en réalité autre chose : la mise en cache est effectuée depuis le réseau vers le réseau, puis le chargement est effectué depuis le réseau... Cela peut constituer un "goulot d'étranglement" chez le client.
Mieux vaut un hôte ESX avec des disques locaux, et encore mieux un hôte ESX avec des SSD locaux. Cela permettrait de réduire encore les temps de recherche, surtout si une recherche fournit tellement de pièces que tout ne tient plus dans la mémoire principale. De plus, on n'a alors pas de goulot d'étranglement du réseau.
