Accéder au contenu principal

[Magento 2]Le système de cache

A la lecture de l'article d'Alan Kent sur le système de cache de Magento 2, on ne peut que se réjouir d'une vraie prise de conscience du problème qui avait été déjà pris en compte avec la mise en place des modules Redis de Colin Mollenhour dans Magento 1.8 qui avait permis d'améliorer considérablement les performances sur des Magento à moyen et gros volumes. J'avais pris l'initiative de mettre en place ces deux modules (Session et Backend) sur des 1.7 au grand soulagement des clients qui ont vu les temps de réponses s'améliorer avec un temps de chargement parfois divisé par trois.
Pour la future version de Magento, le système de cache se basera a priori sur un cache de page complète du type Varnish avec un chargement en Ajax pour les parties de la pages qui sont spécifiques à l'utilisateur. On pense notamment au récapitulatif du panier, aux liens vers les différentes parties du compte... En s'appuyant tout de même sur le cache du navigateur pour cacher les données qui ne sont pas à même de changer très vite comme le nom de l'utilisateur. De manière générale, toutes les requêtes en GET seront traitées comme des données qui peuvent être stockées dans le cache du navigateur pour une utilisation future alors que les requêtes en POST seront stockées mais uniquement après une vidange du cache du navigateur. Partant de là, les modules devront être conçu afin de respecter cette façon de faire et permettre d'augmenter les performances de Magento grâce à un cache élaboré. La mise en place de Edge Side Includes (ESI) permettra en outre de cacher le squelette de la page et d'appeler des sous-parties.
Du côté du cache public, différentes approches permettront de donner une période avant l'invalidation du cache. Par exemple, une image pourra être caché sur un très long terme (la période de validité dans le cache du navigateur doit rester définie par Apache à mon avis) alors que le stock devra être rafraîchi après chaque achat. Il sera aussi possible de mettre les formulaires en cache en gardant la protection contre les XSRF (CROSS-Site Request Forge) mais ce n'est pas encore détaillé.

Pour l'instant, seul Varnish est implémenté mais la modularité est prévue pour le futur.

Commentaires

Posts les plus consultés de ce blog

[PHP] Faire un petit MVC avec des routes

Pour bon nombre de petits projets, il n'est pas nécessaire de taper dans les frameworks MVC comme Zend ou Symphony qui sont très lourds et un petit truc maison doit suffire. Je vais essayer de donner quelques tuyaux pour pouvoir faire son MVC maison avec des routes qui dirigent vers les contrôleurs et les actions.
Tout d'abord, il faut créer un fichier index.php à la racine de votre site qui va contenir le lien vers tout ce dont vous avez besoin pour faire vos routes. Ensuite, vous devez créer un dossier controlleur (si vous voulez reproduire la faute de frappe de l'exemple) dans lequel vous aurez tous vos contrôleurs. Vous pouvez éventuellement diviser ce dossier en plusieurs dossiers distincts qui contiendront les différentes parties de votre site. Veillez à appeler vos classes en rapport avec vos règles de is_callable. Dans mon exemple, le chemin vers le dossier est en minuscule et la première lettre du fichier est en majuscule. Par exemple : la classe /controlleur/fro…

Ajouter un administrateur à Magento 1 en SQL

On vous balance sur un projet, vous devez récupérer la base de données et travailler dessus dans votre environnement de développement. Le problème est que vous n'avez pas d'accès à l'administration car vous n'avez pas d'utilisateur créé en production ou en staging. Ce n'est pas une fatalité !

Il est possible de créer facilement un utilisateur qui aura les rôles suffisants dans Magento avec seulement un accès à la base de données. Pour faire cela, il faut comprendre que les administrateurs sont inscrits dans une table et leur rôle dans une autre. Dans le script suivant, on créera un administrateur avec les pleins pouvoirs mais vous pouvez adapter ce script à vos besoin en jetant un oeil à la table admin_role et en modifiant parent_id dans le script. La colonne parent_id définit le parent du rôle en question pour l'utilisateur. Si vous voulez créer un utilisateur avec des pouvoirs différents, regardez le rôle qui correspond au pouvoir que vous accorder et mo…

Modifier le type d'entrée d'un attribut produit dans Magento

Aujourd'hui, suite à une modification différente via l'administration dans deux instances du même site (dev et staging), j'ai du modifié le type d'un attribut de liste déroulante vers multi-select. Pour y parvenir, j'ai du faire quelques modifications dans la base de données directement puisqu'il n'est pas possible de le faire via l'administration.
Pour faire cette modification, je me suis basé sur un gist que j'ai adapté selon mes besoins :


Et voilà !