Grimoire-

Command

.es

Pelican static websites are fitted with a Makefile that allows several methods to upload your web site its hosting.

I tested lftp which is a full-featured FTP client capable of uploading only the locally changed files, to save some time and bandwidth. Unfortunately, to do so lftp compares local and distant files one by one, accumulating the network latency overheads at each file.

rsync (which is another file-transfer tool) can also avoid to transfer unmodified files, but it locally compiles the required informations to check that (date of modification, size of file, even checksums if there is still an ambiguity), and then sends this bundle all at once to the hosting machine (via an ssh ciphered channel). This other machine needs to have also rsync on its side to handle the bundle, and will answer which files are to be uploaded. At its turn, the 1st machine will send all the needed files in one transfer.

If the static website counts 180 files of a few kilo-bytes each, the difference in total processing time, when using a 4G internet access (best ping of 50ms), is quite outstanding :

Each times, the static website compilation is included, for 2s.

Alas, I took many years to actually do the comparison (and to setup the hosting to support rsync).

PS: When using a "tag cloud" included in the pages of the web site, each new content is susceptible to modify the "tag cloud" in all the existing pages. Using a regular FTP client to upload the on-growing 8.6MB of the website each time entirely would not have been a bad idea and it would have use only 25s on the same connection (350 kilo-bytes by seconds upload rate).

Le générateur de sites statiques Pelican est fourni avec un Makefile qui propose plusieurs méthodes de téléversement du site vers son hébergement.

J’ai testé la méthode basée sur lftp, un client FTP très complet, notamment capable de n’uploader que les fichiers qui ont été changés localement pour d’économiser du temps et de la bande passante. Malheureusement, pour en arriver là, lftp compare les fichiers locaux et distants un par un, accumulant ainsi les délais de latence du réseau, pour chaque fichier.

rsync (qui est un autre outil de transfert de fichier) permet également de s’éviter l’envoi des fichiers non modifiés, mais il fait ça en compilant localement les informations nécessaires à la comparaison (date de modification, taille du fichier voire somme de contrôle s’il persiste une ambiguité) et les envoi toutes d’un coup sur la machine de destination (par un canal chiffré ssh). Cette deuxième machine doit elle aussi avoir rsync de son côté pour analyser (automatiquement) les informations transmises et répondre par la liste des fichiers qu’il faut mettre à jour. La première machine enverra alors tous ces fichiers d’un coup.

S’il s’agit d’un site statique comptant 180 fichiers de quelques kilo-octets chacun, la différence de temps de traitement pour la mise à jour du site, sur une connexion internet 4G (avec 50ms de ping au mieux), est assez remarquable :

Et chaque fois, le temps de compilation du site lui-même est compris, pour environ 2s.

Malheureusement, il m’a fallu plusieurs années pour comparer les deux méthodes (et donc configurer l’hébergement pour pouvoir faire le transfert via rsync).

PS: Lorsqu’on utilise un "nuage d’étiquettes" sur les pages du site, chaque nouveau contenu est susceptible de modifier cette partie des pages existantes. On peut donc noter que transférer les 8,6 Mo du site à chaque fois n’aurait pas été une mauvaise idée et n’aurait d’ailleurs pris que 25s sur la même connexion (350ko/s d’upload).