Amélioration possible sur un serveur dédié
Le site sur l'état de la vaccination COVID 19 en France présente
plusieurs particularités :
- Nombre de pages à visualiser assez limité (quelques dizaines en
tout):
- 10 pages pour la vaccination à ce jour,
- 4 pages pour les graphiques d'évolution de la vaccination,
- moins de 40 pages pour les différents tableaux d'évolution
de la vaccination.
- Pages identiques à fournir à tous les utilisateurs du site,
- Les utilisateurs du site pourraient se compter en dizaines ou
centaines de milliers par jour si ce site était connu comme le
site officiel,
- L'actualisation périodique nécessaires des pages du site est
nécessaire,
- Les mises à jour des pages peuvent être réalisées
automatiquement,
- Ces mises à jour ne sont pas très fréquentes (1 fois par jour,
5 jours par semaine) et le meilleur moment pour les faire est
connu (à quelques minutes près).
Sur la version du site qui est présentée, ce sont les scripts PHP appelés
au moment où un utilisateur veut visualiser une page qui se chargent
de :
- vérifier si une mise à jour des fichiers CSV locaux est
opportune,
- faire cette mise à jour lorsque c'est le cas,
- mettre à jour les images lorsque les fichiers CSV locaux ont
changé,
- générer la page html à afficher.
On peut rendre le serveur web plus performant en ne demandant pas
de faire le plus gros du travail au moment où l'utilisateur demande
une page.
Premier niveau : actualisation automatique des fichiers CSV
locaux et des images
Les systèmes d'exploitation actuels disposent d'un système de tâches
périodiques : cron sur les systèmes d'exploitation dérivés d'UNIX
(GNU/Linux, Mac-OS ...), mais Windows a aussi son système de tâches
périodiques.
Les fichiers CSV de référence qui contiennent les statistiques de
vaccination sont actualisés 5 fois par semaine sur un laps de temps
très court à partir de 19 H 05 (il resterait à savoir si l'heure
d'actualisation est basée sur l'heure officielle (qui est décalée 2
fois par an en Europe tant que l'heure d'été n'a pas été supprimée),
ou sur l'heure solaire.
Des outils du système d'exploitation dérivés d'UNIX (awk/gawk, sed,
grep et ses dérivés, sort, ...) permettent de fabriquer en une
fraction de seconde les fichiers CSV locaux à partir des fichiers
CSV de référence qu'on peut récupérer par une commande comme
wget s'ils ne sont pas accessibles directement depuis un
disque dur monté en réseau.
Une fois les fichiers CSV locaux actualisé, on ferait de même pour les
images variables du site (bargraphes et graphiques d'évolution).
La tâche périodique qui fait ces deux mise à jour serait lancée à
une heure précise peu après l'heure supposée d'actualisation des
fichiers de référence (19 H 10, 19 H 15 ou
19 H 20).
A part durant les quelques minutes qui suivent l'actualisation réelle
des fichiers de référence, le site web afficherait toujours des données
(textuelles et graphiques) à jour en ayant juste besoin de créer la
page HTML qui utilise les données de la dernière version du fichier CSV
local.
Remarque : Dans le cas de ce site-ci, où c'est le script PHP
appelé au moment d'afficher une page qui vérifie si le fichier CSV local
doit être mis à jour, afin de limiter des vérifications inutiles trop
fréquentes, on ne vérifie le fichier CSV de référence qu'au maximum une
fois par demi-heure pour l'état de la vaccination à ce jour.
Le retard moyen pour la prise en compte de la nouvelle version du fichier
CSV est de 15 minutes (entre 0 et 30), et pour ça, on fait jusqu'à 48
vérifications par jour du fichier CSV de référence.
Les fichiers CSV locaux sur l'évolution de la vaccination ne sont
actualisés que si le fichier local sur la vaccination à ce jour l'a
été au préalable.
Par rapport à cette manière de procéder, une mise à jour automatique
seulement une fois par jour mais au bon moment (avec juste quelques
minutes de retard sur l'arrivée supposée des nouvelles données) demande
encore moins de ressources machine pour une meilleure réactivité.
Deuxième niveau : mise en cache des pages HTML
Avec la tâche périodique qui se charge de maintenir à jour les fichiers
CSV locaux et les images, il ne reste plus au script PHP qu'à générer
la page HTML à afficher dans le navigateur.
Le problème est que cette page pourra être demandée de nombreuses fois
dans la journée par des utilisateurs différents, alors que son contenu
ne changera qu'une fois par jour (5 fois par semaine à présent).
De la même manière que sur ce site-ci, un script PHP peut fabriquer et
garder sur le disque dur du serveur un fichier CSV local, il est possible
de demander au script PHP d'écrire dans un fichier le contenu de la page
HTML à envoyer, puis d'envoyer directement cette page à tous les
utilisateurs du site qui la demandent.
Le processus obéirait à l'algorithme suivant :
SI le fichier HTML en cache est plus ancien que le fichier CSV local ALORS
Créer une nouvelle version de ce fichier HTML
FIN SI
Envoyer au navigateur web le fichier HTML en cache
Dans le cas particulier des graphiques d'évolution de la vaccination,
seuls ces graphiques évoluent chaque jour. La page HTML en cache n'a
pas besoin d'être réactualisée.
Troisième niveau : actualisation des pages HTML par la tâche
périodique
On a déjà une tâche périodique qui actualise au bon moment dans la
journée les fichiers CSV locaux et les images évolutives du site. Il
est possible juste après de générer la nouvelle version des pages
HTML en cache à partir des fichiers HTML de référence, des fichiers
CSV locaux et de quelques scripts.
Ces fichiers HTML étant mis à jour automatiquement au bon moment,
le seul travail pour le serveur web sera de les envoyer tels quels
0 ceux qui consultent le site lorsqu'ils en font la demande.
En conclusion
Alors que le site officiel sur la vaccination COVID 19 en France (et
beaucoup de sites web actuels) abusent du javascript et nécessitent
pour chaque utilisateur qui consulte une page beaucoup de calculs du
coté du navigateur, qui quelquefois peut se trouver bloqué pendant de
nombreuses secondes, il est facile de réaliser ces traitements en PHP
coté serveur dans un laps de temps beaucoup plus bref.
Et si le site est un site d'information dont les pages en nombre
limité n'évoluent pas trop souvent, en préparant ces pages à l'avance,
on pourra aussi réduire la charge de calcul coté serveur.
Il suffit d'avoir la bonne approche qui, presque toujours consiste
à utiliser les standards du web tels qu'ils existent depuis quelques
décennies.