Dans certains projets le client a des besoins particuliers pour assurer des performances et une sécurité maximale.
Son exigence était simple : avoir une copie statique complète de son site à déployer toutes les 30 minutes environ.
Je me propose de vous expliquer les différentes approches testées pour vous révéler celles qui sont les plus efficaces.
36. < Plus loin/>
Voir du côté de GatsbyJS
● Avantages
○ Créé pour la performance
○ Statique complet
○ Pré-chargement de données
● Moins
○ Stack plus compliquée
○ Scalable ?
○ Compétences REACT ++
36
Page de couverture
1 - Remplacer par la bonne date
2 - Le titre principal est en noir, encadré par “<” et “/>” en blanc.
Ce titre est de maximum trois lignes.
PAGE À REPRENDRE TEL QUEL
PAGE À REPRENDRE TEL QUEL
~ 5000 articles
30 000 images : 20 Go de données
40 catégories
10aine ~ d’étiquettes
+ de 100 partenaires
Calculons : 5000 articles à 10 par page : 500 pages + la pagination des catégories + celles de étiquettes + sitemap + landing pages
= ~10 000 urls à exporter en 15 minutes = 0,09 secondes maximum par page ~
Mais initialement plus de 20 000 articles, des centaines d’étiquettes et des dizaines de catégories !
~ 5000 articles
30 000 images : 20 Go de données
40 catégories
10aine ~ d’étiquettes
+ de 100 partenaires
Calculons : 5000 articles à 10 par page : 500 pages + la pagination des catégories + celles de étiquettes + sitemap + landing pages
= ~10 000 urls à exporter en 15 minutes = 0,09 secondes maximum par page ~
Mais initialement plus de 20 000 articles, des centaines d’étiquettes et des dizaines de catégories !
PAGE À REPRENDRE TEL QUEL
Plus on a contenus, plus ça va être long, ces outils exportent et copient les médias etc.
Ils ne font pas de différentiels efficaces entre les exports,
Chaque page générée = 2 processus PHP, un pour le “worker” un pour la génération de la page.
Tentative 1 : serveur totalement perdu, (plus de 600 de load average) pour une très gros serveur (24CPU, 64 de RAM) pour une config NGINX prévue pour consommer au plus.
Plus de 4 heures d’export ...
On ne prend pas les médias : rsync
On essaye d’optimiser les plugins avec des commandes WPCLI:
On est entre 40 et 50 minutes ! OUF ! mais ce n’est toujours pas ça !
Tentative 3 :
Ajout de WP-Rocket, on met en cache et l’exportateur récupère tout !
Mieux, mais les exports prennent entre 30 et 40 minutes, toujours pas assez…
Des urls sont ratées dans l’export…
WGET : un peu comme curl, mais en moins compliqué, plus user friendly.
Permet d’exploiter du HTTP, HTTPS, FTP en non interactif, une fois la commande lançée pas d’intervention.
Peut être utilisée pour télécharger le contenu d’un FTP en local facilement par exemple.
Permet surtout de télécharger et faire des miroirs de sites, complètement autonomes, vive l’option --mirror !
Tentative 3 :
Ajout de WP-Rocket, on met en cache et l’exportateur récupère tout !
Mieux, mais les exports prennent entre 30 et 40 minutes, toujours pas assez…
Des urls sont ratées dans l’export…
Tentative 3 :
Ajout de WP-Rocket, on met en cache et l’exportateur récupère tout !
Mieux, mais les exports prennent entre 30 et 40 minutes, toujours pas assez…
Des urls sont ratées dans l’export…
-X : pour ne pas prendre les médias
-ignore-tags : pour ne pas prendre les placeholder de lazyload, pas les scripts car urlencodées dans les JSON : incompatible
--mirror : récursif de façon infinie, vérifie le timestamp pour ne pas télécharger 2 fois,
-X : pour ne pas prendre les médias
-ignore-tags : pour ne pas prendre les placeholder de lazyload, pas les scripts car urlencodées dans les JSON : incompatible
--mirror : récursif de façon infinie, vérifie le timestamp pour ne pas télécharger 2 fois,
Si on DL des pages disant html dans le content-type et que ça ne fini pas par .html alors il transforme en .html exemple les fichiers .asp.
Télécharger tout ce qui est nécessaire au fonctionnement de la page, quelque soit la profondeur atteinte.