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
  • each user can sends requests to the same application; if you have tens or hundreds of users, you can easily understand that optimising your web application is an important task.

You have to think about a web publication for many users rather than the display of a map to a single user.

By default, for each QGIS layer you add to your Lizmap project, you can choose from the Lizmap plugin whether to toggle the layer visibility on (checkbox Toggled) at the startup of the application. You have to be careful not to abuse this feature, because if the project contains e.g. 30 layers, Lizmap at startup will send a request to QGIS server for each of them.

If the checkbox Single tile is ticked, this will request 30 images of the size of your browser window. If not, Lizmap, through OpenLayers, will request 30 series of tiles (about 250 by 250 pixels). Each tile is an image, and is created as a function of the total window size and zooming level. Therefore, subsequent users will zoom in the same area, the tiles already generated will be reused.

The tiles can be cached with two non exclusive systems:

  • Server side, on the machine where QGIS server and Lizmap are installed. If the tile has been requested and generated earlier, and not expired, Lizmap will reuse it and send it to the client, avoiding a new request to QGIS server.
  • Client side: tiles will be saved in the browser cache and reused until they expire. This avoid both the request to QGIS server and the internet traffic.

The server cache has to be generated. Read Gestion du cache en tant qu’administrateur to know how to generate the cache.

Afin d’optimiser les performances, il est donc important de comprendre comme Lizmap utilise les tuiles a afficher.

Let’s say you have a screen of 1280 by 768 pixels. If you have all your layers tiled, Lizmap has therefore to show about 5 by 3 = 15 tiles (256 by 256 pixel each) per layer, and more for a larger screen. If surrounding tiles are only partially shown, the total number will be even greater. An average of 20 tiles per layer is a reasonable estimate. With 30 layers, as in our example, this will mean a total of about 20 by 30 = 600 tiles (therefore, 600 requests to Lizmap server) per user, at each startup of Lizmap and for every zoom & pan. If you have 10 concurrent users, this gets quite heavy for the server, if the cache has not been generated previously, and QGIS server has therefore to create them. The time required for each tile will depend heavily on the performance of the server and the complexity of the project.

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)

A typical tile could be around 30 Kb. In our example, the client will therefore download about 20 by 30 = 600 Kb per layer, which, for 30 layers, will give a grand total of about 18 Mb, which is heavy both for the server (lots of connection bandwidth consumed) and for the users (long delay, even with a reasonably fast connection).

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éez 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.
  • Utilisez 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.
  • Do not show all the layers at startup (deactivate the checkbox Toggled as described above). Only very important layers should be visible by default, and users should activate only the layer they need. This allow a sensible reduction in the number of requests, and of the total network traffic.
  • Create groups of layers, and use the option Group as layer in Lizmap plugin. Generally a series of layers of the same general theme can be displayed as a whole, with an appropriate choice of styles. In this case, Lizmap will only show one checkbox for the whole group, and more importantly it will request only one series of tiles for the whole group, thus reducing the number of tiles and server requests, and the total volume of data to be downloaded. The legend of the group will be displayed.
  • Use the option Single tile for some layers. In this case, Lizmap will request only one image per layer, of about the size of the screen, instead of a series of tiles. This will therefore greatly reduce the number of requests to the server. For instance, in our example above, without the optimizations described, if all the layers are displayed, every user will request 30 images (one per layer) for every zoom or pan, instead of 480. The total size of data to be downloaded is however similar. On the other hand, different users will be very unlikely to request exactly the same image, therefore using a cache is pointless in this case, and is avoided by Lizmap (the two options are mutually exclusive). The optimal choice (single tile vs. tiled) is different for different layers. For instance, a complex base layer, created by combining 15 individual layers, will be best used as a group (Group as layer), tiled and cached. A simple linear layer, like a series of bus lines, can be displayed as a single tile.
  • Use the option Hide checkboxes for groups: this avoids the users to click on a group with e.g. 20 layers without really needing it, thus firing a big series of requests to the server. In any case, avoiding groups of more than 5-10 layers is usually good practice.
  • 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
    • use simplified version of a layer to display it at different scales. You can then group the original layer (to be displayed e.g. around 1:1,000) with the simplified versions (to be displayed e.g. around 1:10,000, 1:50,000, etc.), and Goup as a layer to let the user see this as a single layer, using the most appropriate data at each scale
    • 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
    • d’être 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.
    • use an appropriate image format. For the base layers, where you do not need transparency JPEG is usually the best option: the tiles will be smaller, and faster to download. For other layers, try smaller depth PNGs (16bit or 8bit): for some symbols, the visual result may be the same, and the tiles smaller. Have a check to see if the image quality is acceptable in your case
    • Utilisez 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 avoids the automatic download of the legends at startup and at every zoom level. This will be done exclusively on demand, if the legend is displayed, thus saving one request per layer for each zoom.

En détail : comment activer les différents caches

In Lizmap plugin ‣ Layers, you can enable for each layer or group the cache (client and server side) for generated images.

Côté serveur

This feature is not compatible with the option Single tile. Lizmap Web Client can dynamically create a cache tiles on the server. This cache is the storage of the images already generated by QGIS-Server on the server. The Lizmap Web Client application automatically generates the cache as the tiles are requested. Enable caching can greatly lighten the load on the server, since we do not want more QGIS-Server tiles that have already been made.

Pour l’activer, il faut :

  • cocher la case Cache de tuiles serveur
  • specify the expiration time of the cache server in seconds: Expiration (seconds). 0 means no expiration on the server, the tile will be kept on the server until the cache is cleared.

The Metatile option allows you to specify image size in addition for generating a tile. The principle of Metatile is to request the server for a bigger image than hoped, to cut it to the size of the request and return it to the Web client. This method avoids truncated labels at the edges and discontinuities between tiles, but is more resource intensive. The default value is 3,3, an image whose width and height are equal to 5 times the width and height request. This option is useless for rasters.

Note

For vector layers with metatiles, you have to set label position to a fixed position. If the label is very long, do not forget to use a word wrap function or to increase the metatile size a little bit. So labels are displayed in the same area.

Côté client

The Browser client cache option allows you to specify an expiration time for the tiles in the Web browser (Mozilla Firefox, Chrome, Internet Explorer, Opera, etc.) cache in seconds. When browsing the Lizmap map with the browser, it stores displayed tiles in its cache. Enable client cache can greatly optimize Lizmap because the browser does not re-request the server for tiles already in cache that are not expired.

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.
  • These two cache systems, server and client, are completely independent of one another. But of course, it is interesting to use the two together to optimize the application and free server resources.

Centraliser le cache via l’intégration de groupes et couches d’un projet parent

In QGIS, it is possible to integrate in a project, groups or layers from another project (which will be called « parent »). This technique is interesting because it allows you to set the properties of the layers once in a project and use them in several other, for example for baselayers. In the « child » projects that integrate these layers, it is not possible to change these properties.

Lizmap uses this feature to centralize the tiles cache. For all child projects using integrated layers of the parent project, Lizmap requests QGIS-Server tiles from the parent project, not from child projects. The cache will be centralized at the parent project and all child projects that use layers benefit the shared cache.

Pour pouvoir utiliser cette fonctionnalité, il faut

  • publier le projet QGIS parent avec Lizmap
    • vous devez choisir la bonne étendue annoncée dans project properties ‣ QGIS Server, 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.
    • It is possible to hide the project from the main page of Lizmap with the check box in Map ‣ Hide the project Web Client Lizmap.
  • ouvrez le projet enfant et intégrez des couches ou des groupes dans ce projet, par exemple orthophoto. Ensuite, vous devez :
    • verify that the announced extent in QGIS project properties ‣ QGIS Server is exactly the same as the parent project.
    • 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)
    • the code of the « Source project » (the name of the parent QGIS project without the .qgs extension) is automatically entered for layers and integrated groups.
  • Publiez le projet enfant sur le client Web Lizmap comme d’habitude.