Le coin de l'open-source géospatial

Optimisation d’une application web

Lorsque nous développons une application web nous faisons généralement attention au développement de fonctionnalités, à corriger les bugs et à développer une interface conviviale. Une étape importante mais souvent sauter consiste à reprendre le développement de l’application pour l’optimiser.
Il y a trois parties qui peuvent être optimiser :

1. le serveur (RAM, processeurs, vitesse du disque dur, paramètre de configuration) ;
2. le traitement des requêtes reçu par l’application (http, sql, etc.) ;
3. le renvoie des résultats de la requête vers le poste client.

L’optimisation du serveur à l’aide des paramètres de configuration ne sera pas traité ici, un document présente une procédure d’optimisation d’un serveur postgreSQL à cette adresse.

Au niveau du traitement des requêtes reçues par l’application, celles-ci sont généralement ralenties du fait du traitement de données spatiales (reprojection des données par exemple) ou de l’utilisation d’une grande quantité de données. Il s’agit dans ce cas de limiter ces traitements. Par exemple au niveau du serveur carto :

• Utiliser des formats de données optimisés pour le serveur : pour mapserver préférez le format shapefile pour de petite quantité de données, PostGIS pour de plus grande quantité. N’hésitez pas à créer des index !
• Éviter d’utiliser des données dans des projections différentes, la reprojection est source de ralentissement et utilise des ressources matérielles importantes.
• Lisez la documentation pour optimiser le serveur cartogaphique : placer les projections utilisées en haut du fichier epsg par exemple, utilisation des index, utilisation de mapserver en mode fast_cgi, etc.
• Utilisez un système de cache des tuiles : Tilecache, geoWebCache, voire même création des tuiles avant mise en production.
• Pour de grosses applications (i.e. avec beaucoup de données et des requêtes assez lourde), on utilisera des tables générées pour éviter de faire des jointure trop lourde. Ces tables sont recréées chaque nuit.
• Utilisez un système de cache pour l’application, bref, pré-caché tout ce qui est possible, par exemple si vous utilisez une requête GetCapabilities d’un serveur WMS ou WFS, vous pouvez mettre en cache le fichier XML. Il est assez rare lorsqu’une application est en production que l’on rajoute des données côté serveur cartographique, ou du moins cela est assez rare, mais une gestion adéquate du cache permettra de mettre à jour ces fichiers (récupération de la date de création du fichier, si trop ancien, on l’efface par exemple).

Côté client, il est possible d’agir bien que cela soit un peu plus complexe :

• Configurer le serveur Apache avec mod_expire (pour mettre en cache les images coté client pendant x heures à définir en fonction de la fréquence de mise à jour). ou le mod_deflate (voir cet article sur le blog de Cédric)
• Éviter de mettre trop de couche dans OpenLayers si vous l’utilisez, à partir d’un moment il faut utiliser une couche (WMS) par serveur WMS et utiliser la fonction mergeParam pour rajouter (merger ou fusionner) les couches proposées par le serveur WMS (suis je clair ?).
• Éviter de mettre trop d’objet vectoriel dans OpenLayers : cela ne sera que plus lisible et ne ralentira pas trop le navigateur, surtout Internet Explorer.
• Éviter d’utiliser du GML, prévilégiez les formats les plus simples : geoJSON, WKT.
• Si vous n’utilisez pas OpenLayers, utilisez un client qui gère le tuilage et permet au navigateur de mettre en cache les images (comme OpenLayers), si le fichier image d’une dalle change de nom, le navigateur devra redemander l’image à chaque fois que vous revenez sur la zone, par contre si le nom du fichier est lié à sa position, alors le navigateur utilisera celle qui est en cache. Pour bien comprendre, regardez les noms des tuiles au sein d’OpenLayers, les tuiles sont définie d’une telle manière que les coordonnées de leur contour sont toujours les mêmes.

Bonne optimisation !

Souscrire aux commentaires de cet article