Hyper File 7 en mode réseau sur un serveur Windows NT4 / Windows 2000 / Windows 2003 : Optimisation de la vitesse I. Préambule

Transcription

1 en mode réseau sur un serveur Windows NT4 / Windows 2000 / Windows 2003 : Optimisation de la vitesse I. Préambule Ce document est fourni à titre purement informatif et n'est pas contractuel. Ces informations sont vérifiées à la date de rédaction de ce document. En raison de l évolution permanente des logiciels, aussi bien de PC SOFT que de Microsoft, ces informations peuvent évoluer à tout moment. II. Introduction La vitesse d'accès à des données en réseau dépend d'un très grand nombre de facteurs (repris dans la partie : "Réseau : De multiples paramètres"). Le facteur le plus important est bien sûr le poste serveur et surtout son système d'exploitation. Il faut donc s'assurer que le système d'exploitation du serveur est bien à jour. Certains utilisateurs de WinDev 7 constatent que l utilisation de sur un serveur Windows produit des performances différentes par rapport à d autres serveurs. Ce document explique les différences qu il est possible d observer sur un serveur Windows, en fonction du paramétrage du serveur et de la programmation utilisée. III. Données sur un serveur Windows Afin de vérifier qu un serveur Windows est à jour, il faut s assurer qu'un service pack récent est appliqué. Soit, au 01/10/2003, le service pack 6 pour Windows NT4, le service pack 4 pour Windows 2000, et la version finale de Windows A. Les performances constatées Voici un tableau récapitulatif des performances constatées de en mode réseau avec un serveur Windows par rapport à avec une autre type de serveur : Serveur Windows Autre serveur (Novell, Linux...) Mono utilisateur Multi-utilisateur en lecture Multi-utilisateur en écriture/blocage Mécanisme spécifique du système qui effectue une optimisation supplémentaire Mécanisme spécifique du système qui effectue une optimisation supplémentaire Note aux utilisateurs de Hyper File 5 : La version 7 de Hyper File est dans tous les cas plus rapide que la version 5.5 de Hyper File. 1/6

2 B. Explication résumée du mécanisme de verrou opportuniste de Windows Le système de gestion des fichiers des serveurs Windows varie en fonction des accès aux fichiers. Un mécanisme important des serveurs Windows est le "verrou opportuniste" (ou "opportunistic Locking"). Ce mécanisme est propre aux serveurs Windows et est totalement indépendant de WinDev et de Hyper File. Depuis Windows NT 4, service Pack 5, ce mécanisme de «verrou opportuniste» fonctionne obligatoirement pour les serveurs Windows. Voici une rapide explication du "verrou opportuniste" à travers un exemple : Un poste client ouvre un fichier présent sur un serveur Windows. Le mécanisme du verrou opportuniste de Windows rapatrie tout ou partie du fichier dans le cache local du poste client. Les accès suivants au fichier n utilisent plus du tout le réseau, mais utilisent le cache local sur le poste client. Les accès sont donc plus rapides, par contre les données du cache pourraient être différentes de celles du serveur. N postes clients peuvent faire cette manipulation, le mécanisme est identique : chaque poste client rapatrie tout ou partie du fichier en local. Si un poste client écrit (ou bloque) dans ce même fichier, le serveur prévient tous les clients de désactiver leurs caches locaux afin d assurer l intégrité des données. Les prochains accès au fichier par les postes clients s effectuent via le réseau. La vitesse d accès devient celle du réseau (plus lent). Les verrous opportunistes sont réactivés uniquement si toutes les applications qui utilisent le fichier referment ce fichier. Le mécanisme de verrou opportuniste de Windows ne permet donc d optimiser que les accès réseau en mode «client unique» ou en mode «clients multiples mais en lecture seule». Il est important de comprendre que l accès n est pas «plus lent» en mode multi utilisateur», mais que c est l accès en mode «mono utilisateur» qui est optimisé par les serveurs Windows récent! Il est tout à fait normal de constater des différences de performances dès la 2 connexion en mode modification. Notez que les performances, pour un réseau correctement dimensionné, seront identiques pour 2 ou 50 postes! Les performances sont alors similaires aux réseaux utilisant d autres logiciels serveurs : Linux, Novell C est le mécanisme de gestion du verrou opportuniste de Windows qui implique cela. Note : le test professionnel des performances d une application multi utilisateur s effectuera bien entendu en mode multi utilisateur sur des données réelles. On comprend aisément qu un test mono utilisateur produira des performances optimisées mais qui ne correspondent à aucune réalité. Le type d accès en mode mono utilisateur peut masquer des erreurs de conception de l application. (voir plus loin dans ce document). IV. Quelques conseils pour accélérer les applications A. Les versions des systèmes d'exploitation des postes clients Les postes clients doivent impérativement être dotés d'une version de Windows appropriée. Windows 95 : Une version B doit au moins être installée. Une version C est conseillée. Il est également conseillé de vérifier la version "vredir" : Vredir.vxd version du 9/11/97 à 11:16a, Vnetsup.vxd du 5/30/97 à 11:12a. Voir article Microsoft : Q : Possible Database File Damage When Data Is Appended Windows 98 : Seconde Edition (SE) nécessaire Windows Millenium : Service Pack 1 nécessaire 2/6

3 Windows NT4 : Windows 2000 : Windows XP : Service Pack 6 nécessaire Service Pack 4 nécessaire Service Pack 1 nécessaire Note : Pour connaître la version de Windows et le service pack installé sur un poste, dans le menu "Démarrer..Exécuter" de Windows, tapez "winver". B. Vérification régulière du réseau La vérification du réseau (et surtout du serveur) est indispensable lors de la mise en place de l'application. Il ne faut toutefois pas négliger des vérifications régulières suites aux modifications du réseau (ajout de postes, changement de câbles,.). N'hésitez pas à faire intervenir un spécialiste du réseau ou du système utilisé afin qu'il vérifie votre configuration. C. Consultez la "Knowledge Base" Microsoft De nombreux phénomènes qui ont une influence sur les performances sont liés au système d'exploitation. Etant donné que les applications WinDev fonctionnent sous Windows, il est important de connaître les phénomènes publiés par son éditeur. Microsoft met à disposition sur son site Internet une base de connaissance avec des articles techniques sur les phénomènes connus. (" Attention pas de "www") D. Attention aux écrans de veille N activez pas d'écrans de veille sur les serveurs. Certains écrans de veille consomment pratiquement 100% des ressources du serveur lorsqu'ils sont actifs, et rendent le serveur quasiment inopérant pour les opérations pour lesquelles il est prévu. E. Attention aux Antivirus Les anti-virus sont une cause importante de ralentissement des accès aux fichiers. En cas d'utilisation d'un anti-virus, il faut demander à exclure de la vérification les fichiers avec.fic,.ndx et.mmo comme extension. Si des ralentissements sont constatés alors qu un anti-virus est actif, désactivez temporairement cet anti-virus et vérifiez à nouveau les performances. Attention de bien vérifier l'antivirus du serveur, mais aussi de chacun des postes clients. Un anti-virus sur un seul poste peut diminuer les performances de tout le réseau. ATTENTION : Si un anti-virus est désactivé, il doit être réactivé après les tests et après avoir vérifié et/ou modifié ses paramètres. F. Vérification des applications, cas d erreurs constatées Une application qui est destinée à fonctionner en réseau doit être testée en réseau dans des conditions similaires à son utilisation réelle (avec des accès concurrentiels et des fichiers de taille réelle). Les performances d un code qui s exécute en local ou en réseau "mono utilisateur", peuvent être totalement différentes en utilisation réelle sur réseau multi-utilisateurs. Voici une liste non exhaustive d erreurs souvent trouvées dans des applications existantes. Tous ces cas sont issus d une expérience réelle et ont été constatés. 3/6

4 1-90% des cas de lenteurs sont dus à des clés inadaptées aux traitements : Résolution : Définir sous l analyse les clés adaptées Dans vos applications, vérifiez les critères des filtres, vues et requêtes. Afin d'obtenir de bonnes performances en exécution, les fichiers doivent avoir les clés et clés composées adaptées. Les clés nécessaires pour obtenir de bonnes performances sont fonctions des conditions des tris. Un examen de l analyse, des filtres, vues et requêtes doit être fait pour déterminer les meilleurs clés. Il est difficile de spécifier le gain de performance, car les situations peuvent être très différentes. Ce gain peut varier d'un temps de traitement accéléré de 10% jusqu'à des temps de traitements divisés par 100 voire plus. Attention : si le test de performance d une application multi utilisateur est effectué en mode mono utilisateur, les résultats du test sont évidemment irréalistes. Bien évidemment une application doit être testée dans sa configuration d utilisation. 2 - Les fichiers ne sont pas "optimisés" Résolution : Lancer WDOptimiseur, ou prévoir un traitement dans l application (HCalculeStat) Des fichiers pour lesquels les calculs de statistiques (ou re-indexation) ont été effectués récemment seront automatiquement plus performants. Cette opération ne nécessite aucun changement dans l'application. Mais des opérations de maintenance régulières sont impératives si vous désirez conserver des accès rapides à une base de données. Pour optimiser l accès aux fichiers, utilisez l'outil WDOptimiseur fournit en standard avec WinDev, ou une des fonctions HCalculeStat, HReindex. 3 - Utilisation abusive de HCreationSiInexistant Résolution : Ne pas utiliser HCreationSiInexistant lorsque ce n est pas nécessaire, et utiliser le paramètre "houverturedifférée" lorsque que HCreationSiInexistant est nécessaire Il est fréquent de retrouver dans des applications une instruction HCréationSiInexistant("*") ou une série de HCréationSiInexistant() dans le code d'initialisation du projet. Cette fonction effectue un grand nombre de vérifications et de recherches, et utilise donc du temps machine. Pour éviter ce temps, vous pouvez demander un contrôle différé en utilisant le paramètre "houverturedifférée" avec la fonction HCréationSiInexistant. Mieux encore, vous pouvez utiliser cette instruction que pour les fichiers susceptibles d'être supprimés ou recréés. Ce changement peut faire gagner plusieurs dizaines de secondes au lancement d une application si elle manipule un grand nombre de fichiers. 4 - Initialisations sans raison ou mal placées Résolution : Supprimer les initialisations inutiles, ou les déplacer à l endroit approprié. Lorsque vous initialisez des fenêtres qui contiennent plusieurs plans ou plusieurs onglets, n'initialisez pas tous les plans et les onglets dès l'ouverture de la fenêtre. N'exécutez les vues et requêtes des autres plans qu'au moment où l'utilisateur y accède. Par contre utilisez HOptimiseRequête( ) dès le code d'ouverture de la fenêtre pour que l'exécution ultérieure de ces requêtes soit encore plus rapide. 5 - Sources de données dynamiques (non définies sous l éditeur de requêtes ou d analyse) mal définies Résolution : Utiliser le type "Source de données" pour chaque source de données dynamique. Lors de la création de vues par HCréeVue, ou de requêtes par HExécuteRequêteSQL(), il faut indiquer un nom. Ce nom permet ensuite de manipuler la source de données (vue ou requête) comme un fichier. 4/6

5 Pour récupérer le contenu des rubriques, il suffit de faire NomVue.NomRubrique ou NomRequete.NomRubrique. Sous l'éditeur de code NomVue (ou NomRubrique) n est pas reconnu. Pour que le compilateur du W- Langage reconnaisse vos vues et requêtes il est nécessaire de les déclarer. Nous vous conseillons d'utiliser le type de variable "source de données" pour les déclarer (cf. documentation). 6 - Utilisation d indirection sur rubrique, sans en préciser le type Résolution : Préciser le type de l indirection En WinDev 7, il est possible d'utiliser l'indirection (les accolades { } ) pour construire dynamiquement un nom rubrique (ou de variable...). Les indirections permettent de créer des codes génériques, mais ces codes sont un peu plus lents. Ainsi un code qui fait des lectures, modifications ou ajouts et qui utilise l'indirection peut être plus lent dans la résolution des indirections que dans les opérations réelles sur les fichiers Hyper File. Afin d'accélérer les traitements qui utilisent l'indirection, il est possible de spécifier le type d'indirection. Exemple : {NomFichier+"."+NomRubrique,indRubrique}=5 7 Les autres cas Résolution : Rechercher l'origine de la lenteur, et adapter le code ou l'analyse. Il existe d autres types d erreur à ne pas commettre (parcours ou initialisations inutilement multiples ), ou d autres types d optimisation possible (sur un réseau lent, utilisation des fonctionnalités de l'accès distant Hyper File (RPC) par exemple. Chaque cas est un cas particulier, mais la règle générale est que lorsqu une lenteur est détectée, celle-ci peut être éliminée en recherchant l origine. G. PC SOFT peut vous aider à optimiser Si vous désirez que PC SOFT étudie une application et son code source, 2 solutions sont envisageables : - Souscription d'un contrat Assistance Directe (détail & tarif disponibles sur - Intervention sur site d un ingénieur spécialisé de PC SOFT. N'hésitez pas à contacter le service commercial de PC SOFT afin de recevoir une proposition commerciale. Notez toutefois que les interventions de PC SOFT ne concernent que les logiciels édités par PC SOFT, et que nos ingénieurs n interviennent pas dans les configurations réseau ou paramétrages de Windows par exemple (même si leur expérience leur permet souvent de donner des conseils pertinents dans le domaine de l'utilisation d'un réseau donné). V. Paramétrage d'un réseau A. De multiples paramètres Un réseau est constitué d'un grand nombre d'éléments, et chacun de ces éléments peut être à l'origine de ralentissement ou d'un dysfonctionnement du réseau. Exemples : - 2 cartes TCP/IP avec la même adresse, - Pilote de carte vidéo entrant en conflit, - Pilote d'imprimante entrant en conflit, - Type et vitesse du disque dur, 5/6

6 - Serveur de réseau présentant des bugs (voir sur le site de l'éditeur la présence de service pack à installer), - Les performances d'un réseau à 100 mégas bits peuvent être totalement effondrées par une simple carte d'un PC à 10 mégabits, - La présence de perturbations électromagnétiques à proximité des câbles (machine outil, transformateur, aimant,...) - etc. Chaque serveur réseau a des incompatibilités (cartes réseau, versions de Windows, imprimantes...), vérifiez-les régulièrement sur le site de l'éditeur de votre serveur. En cas de doutes, faites appel à une société spécialisée, agréée par l'éditeur de votre serveur de réseau. Un réseau ne s'installe pas comme un PC isolé, cela demande des compétences particulières. B. Cas fréquent des cartes réseau Certaines cartes réseau sont beaucoup plus performantes que d autres cartes, il est donc important de vérifier les cartes réseau installées. Par ailleurs les cartes réseau utilisent des drivers pour lesquels des mises à jour importantes peuvent exister. Consultez le site de leurs constructeurs. Un pilote trop ancien peut être à l'origine de ralentissement important (fréquemment un facteur 2). Exemple des cartes 3 COM 3C590 Article Microsoft Q : Network Errors Using 3COM 3C590 NIC In Windows NT VI. Moteur Hyper File en technologie "Client/Serveur" Afin de s'affranchir de certaines contraintes liées à l'installation du réseau, nous vous rappelons qu'un moteur Hyper File Client/Serveur pour Windows et pour Linux est annoncé pour Ce moteur Client/Serveur utilisera (entre autre) de nombreuses nouvelles optimisations pour obtenir des résultats toujours plus rapides, dans toutes les situations. 6/6