Optimisation
Concepts généraux
La vitesse de rendu est cruciale pour une application WebSIG, plus que dans une application bueautique :
les internautes s’attendent à ce que tout soit disponible presque immédiatement
chaque utilisateur peut envoyer des requêtes à la même application ; si vous avez des dizaines ou des centaines d’utilisateurs, vous pouvez facilement comprendre que l’optimisation de votre application Web est une tâche importante.
Vous devez penser à une publication Web pour de nombreux utilisateurs plutôt qu’à l’affichage d’une carte pour un seul utilisateur.
Par défaut, pour chaque couche QGIS que vous ajoutez à votre projet Lizmap, vous pouvez choisir depuis le plugin Lizmap si la visibilité de la couche doit être activée (case à cocher Cochée) au démarrage de l’application. Vous devez faire attention à ne pas abuser de cette fonctionnalité, car si le projet contient par exemple 30 couches, Lizmap au démarrage enverra une requête au serveur QGIS pour chacune d’entre elles.
Si la case Tuile unique est cochée, cela demandera 30 images de la taille de la fenêtre de votre navigateur. Sinon, Lizmap, via OpenLayers, demandera 30 séries de tuiles (environ 250 par 250 pixels). Chaque tuile est une image, et est créée en fonction de la taille totale de la fenêtre et du niveau de zoom. Par conséquent, si les utilisateurs suivants zooment sur la même zone, les tuiles déjà générées seront réutilisées.
Les tuiles peuvent être mises en cache avec deux systèmes non exclusifs:
Côté serveur, sur la machine où le serveur QGIS et Lizmap sont installés. Si la tuile a été demandée et générée précédemment, et qu’elle n’a pas expiré, Lizmap la réutilisera et l’enverra au client, évitant ainsi une nouvelle demande au serveur QGIS.
Côté client : les tuiles seront enregistrées dans le cache du navigateur et réutilisées jusqu’à leur expiration. Cela évite à la fois la demande au serveur QGIS et le trafic internet.
Le cache du serveur doit être généré. Lisez Gestion du cache en tant qu’administrateur pour savoir comment générer le cache.
Afin d’optimiser les performances, il est donc important de comprendre comme Lizmap utilise les tuiles a afficher.
Disons que vous avez un écran de 1280 par 768 pixels. Si vous avez toutes vos couches tuilées, Lizmap doit donc afficher environ 5 par 3 = 15 tuiles (256 par 256 pixels chacune) par couche, et plus pour un écran plus grand. Si les tuiles environnantes ne sont que partiellement affichées, le nombre total sera encore plus élevé. Une moyenne de 20 tuiles par couche est une estimation raisonnable. Avec 30 couches, comme dans notre exemple, cela signifie un total d’environ 20 fois 30 = 600 tuiles (donc 600 requêtes au serveur Lizmap) par utilisateur, à chaque démarrage de Lizmap et pour chaque zoom et déplacement. Si vous avez 10 utilisateurs simultanés, cela devient assez lourd pour le serveur, si le cache n’a pas été généré précédemment, et que QGIS Server doit donc les créer. Le temps requis pour chaque tuile dépendra fortement de la performance du serveur et de la complexité du projet.
La taille de chaque tuile va dépendre de:
le type de données (raster ou vecteur simple, ou combinaison de plusieurs couches)
le format d’image choisi (PNG, JPEG)
Une tuile standard est à peu près d’environ 30 Kb. Dans notre exemple, le client va donc télécharger environ 20 par 30 = 600 Ko par couche, ce qui, pour 30 couches, donnera un total d’environ 18 Mo, ce qui est lourd à la fois pour le serveur (beaucoup de bande passante consommée) et pour les utilisateurs (délai important, même avec une connexion raisonnablement rapide).
Ces calculs montrent clairement que pour obtenir de bonnes performances en webmapping, vous devez faire des choix et simplifier autant que possible.
Si l’on regarde, par exemple, l’approche adoptée par Google Maps ou des services similaires, il est évident que, outre des serveurs puissants, ils ont simplifié le plus possible : une seule série de tuiles comme couche de fond, et très peu de couches (et pas toutes en même temps). Même si vous ne pouvez pas créer une carte aussi simple, il est important de savoir quelles couches doivent absolument être affichées au premier affichage de la carte et quels compromis sont acceptables pour vos utilisateurs.
Si votre projet a 50 couches à activer et désactiver, la grande majorité de vos utilisateurs ne sélectionneront jamais la plupart d’entre elles. Bien sûr, il existe des cas d’utilisation réels où des couches individuelles doivent être affichées de façon sélective, et il n’est donc pas possible de les regrouper pour réduire le nombre de couches affichées.
Astuces
Pour optimiser votre application autant que possible, nous vous proposons de :
Créer des projets QGIS distincts, et donc des cartes Lizmap différentes, pour différents objectifs, regroupant ainsi les données dans des thèmes logiques. Par exemple, une carte sur le développement urbain avec peut-être 10 couches et une sur l’environnement, avec environ 5 couches, est généralement plus lisible, et beaucoup plus rapide, qu’un seul projet complexe avec toutes les données. L’ajout d’une petite image pour chaque projet aidera les utilisateurs à sélectionner le projet pertinent à première vue. Vous pouvez également partager certaines couches entre différents projets, via le mécanisme d’intégration dans QGIS.
Utiliser l’option Seulement des cartes dans l’interface Web d’administration. Cette option permet à l’utilisateur de passer automatiquement d’une carte à une autre, via le bouton Accueil, en conservant autant que possible la localisation et le niveau de zoom. Dans ce cas, la page d’accueil de Lizmap avec la liste des projets et leurs vignettes n’est pas affichée, et l’utilisateur est dirigé automatiquement vers l’un des projets, au choix de l’administrateur.
Ne pas afficher toutes les couches au démarrage (désactivez la case à cocher Cochée comme décrit ci-dessus). Seules les couches très importantes doivent être visibles par défaut, et les utilisateurs doivent activer uniquement la couche dont ils ont besoin. Cela permet une réduction sensible du nombre de requêtes et du trafic réseau total.
Créer des groupes de couches et utiliser l’option Groupe comme une couche dans l’extension Lizmap. Généralement, une série de couches du même thème général peuvent être affichée ensemble, avec un choix approprié de styles. Dans ce cas, Lizmap affichera seulement une case à cocher pour l’ensemble du groupe, et surtout il ne demandera qu’une seule série de tuiles pour tout le groupe, réduisant ainsi le nombre de tuiles et de requêtes au serveur, et le volume total de données à télécharger. La légende du groupe sera affichée.
Utiliser l’option Image non tuilée pour certaines couches. Dans ce cas, Lizmap va requêter une seule image par couche, d’à peu près la taille de la fenêtre du navigateur, plutôt qu’un ensemble de tuiles. Cela va permettre de grandement réduire le nombre de requêtes vers le serveur. Dans l’exemple ci-dessus, sans les optimisations décrites, si toutes les couches sont affichées, chaque utilisateur va requêter 30 images (une par couche) pour chaque zoom ou déplacement, plutôt que 480. La taille totale des données à télécharger est cependant à peu près la même. Par contre, il est peu probable que différents utilisateurs requêtent exactement la même image, par conséquent utiliser un cache n’a pas d’intérêt dans ce cas, et est évité par Lizmap (les deux options sont mutuellement exclusives). Le choix optimal (tuile unique ou tuiles multiples) se fait selon le type de couche. Par exemple, un fond de carte complexe, créé en combinant 15 couches individuelles, sera optimisé en regroupant ces dernières dans un groupe (Groupe comme une couche), tuilé et mis en cache. Une couche simple linéaire, comme un ensemble de lignes de bus, peut être affiché avec une tuile unique.
Utiliser l’option Cacher les cases à cocher des groupes : ceci permet d’éviter que les utilisateurs ne cliquent sur un groupe avec par exemple 20 couches sans que ça leur soit vraiment utile, ceci provoquant un grand nombre de requêtes vers le serveur. Dans tous les cas, il est bon d’éviter d’avoir des groupes de plus de 5-10 couches.
Optimiser les données et le projet QGIS, Comme mentionné ci-dessus, publier une carte sur internet va changer votre point de vue : comme dit précédemment, vous devez avoir à l’esprit que de nombreux utilisateurs peuvent requêter votre serveur en même temps, et donc afin d’éviter une surcharge il est crucial de :
Créer un index spatial pour toutes vos couches vectorielles
Faire une pyramide de toutes vos couches rasters (sauf les très petites)
N’afficher les données qu’à l’échelle appropriée : par exemple, afficher la couche détaillé d’un bâtiment à l’échelle 1:500 000 n’a pas d’intérêt, puisque l’image est quasi illisible, et surcharge fortement le serveur
Utiliser des versions simplifiées d’une couche pour l’afficher à différentes échelles. Vous pouvez ensuite grouper la couche originale (afin qu’elle soit affichée à l’échelle 1: 1 000 par exemple) avec ses versions simplifiées (qui elles seront affichées aux échelles 1:10 000, 1:50 000; etc. par exemple) et utiliser Groupe comme une couche permettant ainsi à l’utilisateur de voir ceci comme une seule couche, et d’utiliser la donnée la plus appropriée à chaque échelle
Faire attention à la reprojection “à la volée” (ALV). Si, par exemple, vous affichez des données en Lambert 93 (EPSG:2154) sur un fond de carte OpenStreetmap ou Google (en Pseudo Mercator, EPSG:3857), QGIS Server nécessite de reprojeter les couches rasters et vectorielles avant de générer la carte. Ceci peut impacter le temps du rendu pour les couches grandes et complexes. En France, vous pouvez éviter la reprojection en utilisant les fonds de carte du Géoportail IGN directement en EPSG:2154
Etre attentif au fait que certaines options de rendu ( par exemples les labels, les expressions, etc.) peuvent demander beaucoup de ressources au serveur
Si vous utilisez PostGIS, optimisez le : créer toujours un index spatial, des indexes pour les données filtrées et pour les clés étrangères, utilisez les paramètres appropriées pour la configuration PostgreSQL, si possible une connexion par socket UNIX plutôt qu’en TCP/IP (pour ceci utilisez des services), etc.
Utiliser un format d’image approprié. Pour les fonds de carte, pour lesquels la transparence n’est pas nécessaire, JPEG est souvent la meilleure option : les tuiles seront plus légères et donc plus rapides à télécharger. Pour les autres couches, essayez le format PNG avec moins de profondeur (16 bit ou 8 bit) : pour certains symboles, le rendu visuel peut être le même avec des tuiles plus légères. Contrôlez si la qualité d’image vous semble acceptable dans votre cas
Utiliser la simplification côté serveur si possible. Lire Simplification côté serveur.
Améliorer votre serveur. C’est peut être utile mais c’est sans intérêt si vous n’optimisez pas votre projet comme expliquez ci-dessus. Dans tout les cas, un serveur avec peu de ressources (par exemple 2 Gb RAM, 2 cœurs à 2,2 GHz) ne sera pas suffisant. Le minimum raisonnable est un quad-core rapide avec 8Gb RAM. Évitez d’installer QGIS Server et Lizmap sur Windows, c’est plus compliqué et plus lent.
Lizmap évite le téléchargement automatique des légendes au démarrage et à chaque niveau de zoom. Cela sera fait exclusivement à la demande, si la légende est affichée, ce qui permet d’économiser une requête par couche pour chaque zoom.
En détail : comment activer les différents caches
Dans :menuselection:``Lizmap plugin –> Couches`, vous pouvez activer pour chaque couche ou groupe le cache (côté client et serveur) pour les images générées.
Côté serveur
Cette fonctionnalité n’est pas compatible avec l’option Tuile unique. Lizmap Web Client peut créer dynamiquement un cache de tuiles sur le serveur. Ce cache est le stockage des images déjà générées par QGIS-Server sur le serveur. L’application Lizmap Web Client génère automatiquement le cache au fur et à mesure que les tuiles sont demandées. L’activation du cache permet d’alléger considérablement la charge du serveur, puisque nous ne voulons plus de tuiles QGIS-Server qui ont déjà été réalisées.
Pour l’activer, il faut :
cocher la case Cache de tuiles serveur
spécifier le temps d’expiration du serveur de cache en secondes : Expiration (secondes). 0 signifie qu’il n’y a pas d’expiration sur le serveur, la tuile sera conservée sur le serveur jusqu’à ce que le cache soit effacé.
L’option Metatile permet de préciser la taille de l’image supplémentaire servant à générer une tuile. Le principe du Metatile est de demander au serveur une image plus grande que celle souhaitée, de la découper à la taille de la requête et de la retourner au client Web. Cette méthode évite les étiquettes tronquées aux bords et les discontinuités entre tuiles, mais est plus gourmande en ressources. La valeur par défaut est 3,3 soit une image dont la largeur et la hauteur sont égales à 5 fois la largeur et la hauteur demandées. Cette option est inutile pour les rasters.
Note
Pour les couches vectorielles avec métatiles, vous devez définir la position de l’étiquette à une position fixe. Si l’étiquette est très longue, n’oubliez pas d’utiliser une fonction de retour à la ligne ou d’augmenter un peu la taille de la métatile. Ainsi, les étiquettes sont affichées dans la même zone.
Côté client
L’option cache du navigateur vous permet de spécifier une date d’expiration en secondes pour les tuiles dans le cache du navigateur (Mozilla Firefox, Chrome, Internet Exploreur, Opéra, etc). Quand vous parcourez la carte avec le navigateur, celui-ci stocke les tuiles affichées dans son cache. Activer le cache client permet grandement d’optimiser Lizmap parce que le navigateur n’a pas à redemander au serveur les tuiles qui sont dans le cache et non expirées.
Avertissement
Les valeurs 0 et 1 sont équivalentes et n’activent pas l’option.
Nous conseillons de mettre la valeur maximale (1 mois soit 24 x 3600 x 30 = 2592000 secondes), sauf bien sûr pour les couches dont la donnée change souvent.
Note
Le cache doit être activé seulement une fois le rendu bien maîtrisé, lorsqu’on souhaite passer le projet en production.
Ces 2 modes de cache, Serveur et Client, sont complètement indépendants l’un de l’autre. Mais bien sûr, il est intéressant d’utiliser les 2 en même temps pour optimiser l’application et libérer les ressources du serveur.
Centraliser le cache via l’intégration de groupes et couches d’un projet parent
Dans QGIS, il est possible d’intégrer dans un projet des groupes ou des couches depuis un autre projet (qu’on appellera « parent »). Cette technique est intéressante, car elle permet de définir les propriétés des couches une seule fois dans un projet et de les utiliser dans plusieurs autres projets, par exemple pour les fonds de carte. Dans les projets « fils » qui intègrent ces couches, il n’est pas possible de modifier ces propriétés.
Lizmap utilise cette fonctionnalité pour centraliser le cache des tuiles. Pour tous les projets fils qui utilisent des couches intégrées du projet parent, Lizmap demandera à QGIS Server les tuiles du projet parent, et non des projets fils. Le cache sera donc centralisé au niveau du projet parent, et tous les projets fils qui utilisent les couches bénéficieront de ce cache partagé.
Pour pouvoir utiliser cette fonctionnalité, il faut
publier le projet QGIS parent avec Lizmap
vous devez choisir la bonne étendue annoncée dans , car cette étendue sera réutilisée à l’identique dans les projets enfants.
vous devez configurer le cache pour les couches à intégrer. Notez également les options choisies ici (format d’image, metatile, expiration) à utiliser telles quelles dans les projets enfants.
Il est possible de masquer le projet dans la page d’accueil de Lizmap via la case à cocher .
ouvrez le projet enfant et intégrez des couches ou des groupes dans ce projet, par exemple orthophoto. Ensuite, vous devez :
vérifier que l”emprise annoncée dans est exactement la même que celle du projet parent.
il faut configurer le cache pour la couche intégrée avec exactement les mêmes options que celles choisies dans le projet parent : format d’image, expiration, metatile
il faut renseigner l’identifiant Lizmap du Répertoire source du projet parent (celui configuré dans l’interface d’administration de Lizmap-Web-Client)
le code du « Projet source » (le nom du projet QGIS parent sans l’extension .qgs) est renseigné automatiquement pour les couches et les groupes intégrés.
Publiez le projet enfant sur le client Web Lizmap comme d’habitude.