Vérification des applications, cas d'erreurs constatés
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.
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 fonction 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.
Dans ce but, WINDEV vous propose un optimiseur de requêtes qui analyse vos requêtes et recherche les clés les plus adaptées à leurs fonctionnements. Pour optimiser une requête, lorsqu'une requête est ouverte sous WINDEV, sous le volet "Requête", dans le groupe "Analyser", cliquez sur "Optimiser la requête".
Il s'agit d'un mécanisme automatique qui donne de bons résultats. Toutefois dans le cas de requêtes complexes ou avec des paramètres optionnels multiples, cette option ne remplace pas la perspicacité d'un spécialiste de base de données.
Il est difficile de spécifier le gain de performance qui peut être obtenu par l'ajout de clés adaptées, 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 pisé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"
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 fourni en standard avec WINDEV, ou une des fonctions
HStatCalcule,
HRéindexe.
3. Utilisation abusive de HCréationSiInexistant
Résolution : Ne pas utiliser
HCréationSiInexistant lorsque ce n'est pas nécessaire, et utiliser la constante
hOuvertureDifférée lorsque que
HCréationSiInexistant 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 la constante hOuvertureDifférée avec la fonction HCréationSiInexistant. Mieux encore, vous pouvez utiliser cette instruction uniquement 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 la fonction
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 la fonction
HCréeVue ou de requêtes par la fonction
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. 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 WLangage 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.
6. Utilisation d'indirection sur rubrique, sans en préciser le type
Résolution : Préciser le type de l'indirection
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 HFSQL. Afin d'accélérer les traitements qui utilisent l'indirection, il est possible de spécifier le type d'indirection. Pour plus de détails, consultez
Opérateurs d'indirection.
Exemple :{NomFichier+"."+NomRubrique,indRubrique}=5
7. Utilisation de l'analyseur de performances pour détecter vos cas de ralentissement
Résolution : Améliorations du code exact qui est jugé trop lent
Il existe d'autres types d'erreur à ne pas commettre (parcours ou initialisations inutilement multiples, ...), ou d'autres types d'optimisation possible (il est par exemple fortement recommandé d'utiliser HFSQL Client/Serveur sur un réseau lent ou avec un accès ADSL).
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.
L'analyseur de performances fournit avec WINDEV est un outil formidable qui permet de déterminer avec précision les codes qui prennent le plus de temps.