Pourquoi Ne Magento Invalidation de la Pleine Page en Cache sur les Produits sauvegarder, en fait, la page n'est pas mis en cache et ce qui ne l'actualisation faire car il n'est pas mis en cache
Donc la mise en Cache est bien sûr ce qui me confond le plus dans Magento, comme il le fait pour la plupart des autres j'en suis sûr. Actuellement l'un des sites, nous travaillons sur est sur de l'Entreprise et utilise FPC bien sûr. Le problème est que nous avons un inventaire de mise à jour qui circule toutes les 15 minutes. Beaucoup de commandes sont placées à la RSE est au téléphone et par le biais d'un catalogue dans un système externe à l'extérieur de Magento.
Toutes les 15 minutes un script est exécuté pour vérifier tout d'inventaire dans le système et de voir si elle diffère alors qu'est-ce que dans Magento. Si il y a une différence d'inventaire est mis à jour dans Magento. À l'aide de tous Magento méthodes, pas de sql ou quelque chose comme ça.
Nous avons toujours eu des problèmes de mise en cache et avez essayé toutes les techniques les plus récentes quand ils sortent. Le dernier a nous d'essayer de le Redis, et nous avons eu un bon succès sur d'autres sites avec elle. Cependant, nous voyons toujours des fous de la charge sur le serveur et il est évident que les pages ne sont pas mises en cache.
Après de creuser dans le code, il semble que jamais après chaque modèle d'enregistrer ou admin contrôleur de produit enregistrer il cherche à voir si le cache doit être invalidé. Il semble que la modification de n'importe quel attribut, eh bien au moins, inventaire marquera FPC comme devant être invalidé.
Je suis confus au sujet de ce que l'invalidation de moyens, parce qu'un retour alors que nous avions une question de soutien à la clientèle à propos de quelque chose de similaire, et ce fut la réponse
Full Page cache obtiendrez d'
invalidé état, à des modifications sur les produits, catégories, CMS
même si le stock est diminué après une vente.Maintenant quand full page cache de invalidé l'état cela ne signifie pas
que quelque chose est changé sur votre frontend toutefois les modifications appliquées
après la dernière actualisation ne sera pas affiché sur le frontend.Cependant si le fait d'avoir la FPC validé en tout temps est un must pour votre
la logique d'entreprise, vous pourriez certainement l'ensemble de votre Installation de Magento à
actualiser automatiquement via cron fonctionnalité aussi souvent que vous le
désir.
Cependant sur tous les tests que j'ai fait, sur les deux 1,9 et 1.11 de l'Entreprise, il apparaît lors de la FPC est invalidée, la réponse n'est pas d'être tiré à partir du cache. Ce qui est contradictoire à ce qu'ils ont dit à ce sujet tout simplement pas d'avoir les mises à jour nouvelles.
Est-il quelque chose que je suis absent? Quelqu'un aurait-il une bonne explication de la façon dont l'invalidation des œuvres dans Magento spécifiquement pour les CPE ou tout bon liens pour bien comprendre le processus et le code?
Vous pouvez essayer vous-même pour n'importe quelle page, pleine page en cache. Mais c'est ma compréhension que la méthode processRequest
dans /app/code/core/Mage/Core/Model/Cache.php
doit définir le contenu du corps avec la réponse en cache et retourne true si la page est mise en cache.
Pour tester aller à n'importe quelle page, assurez-vous que vous l'avez mis en cache et renvoyer true. Aller dans et modification d'un produit, dans notre cas, la quantité. Cela entraînera la nullité de la FPC. Mais maintenant, lorsque vous chargez la page qui a été mis en cache avant de retourner false dans cette méthode et ne pas être une page en cache. Je ne sais pas si cela est exact pour être en mesure de dire si une page est mise en cache ou pas, mais c'est là mon enquête me conduire. S'il vous plaît corrigez-moi si je me trompe.
Mise à JOUR:
Après enquête, j'ai constaté que lorsque vous enregistrez un produit dans l'admin, le contrôleur de l'action
Mage_Adminhtml_Catalog_ProductController::saveAction()
va appeler la méthode suivante
Mage::getModel('catalogrule/rule')->applyAllRulesToProduct($productId)
Puis dans le Mage_CatalogRule_Model_Resource_Rule
classe, le applyAllRulesForDateRange
méthode est appelée et qui déclenche l'événement
catalogrule_after_apply
Qui le Full Page Cache du module d'observation et de tir le nettoyer le cache de la méthode pour la FPC tag. Essentiellement la suppression de toutes les FPC enregistrements de cache.
Je ne vois pas pourquoi cela est nécessaire si avant cela, la logique est la compensation de la FPC des dossiers qui sont liés au produit et de la catégorie des balises. Est-ce un bug?
- Je sais que ce n'est pas directement répondre à votre question, mais je veux juste souligner que votre performance ne devrait pas être pire que si toutes les commandes ont été placées par le biais de Magento, car après la vente de votre stock baisse ce qui permet d'invalider le cache de la même façon que votre tâche cron ne.
- Vrai, je vois votre point là. Puis juste que sa n'avait aucun sens sur le pourquoi de la page n'est pas réellement mis en cache lorsqu'il obtient tout d'abord invalidé.
- Ce n'est pas la réponse que vous voulez, mais j'ai parlé avec d'autres développeurs Magento, et pas un de nous a eu un réel succès avec les actions de FPC. Il vient de nous cause des problèmes. Généralement, nous nous retrouvons à l'aide de Vernis ou de certains autres reverse proxy cache. Le garder séparé de l'interne, qui sont assez compliqué.
- Oui, nous avons fait quelque chose de similaire sur un autre site du client par la mise en cache avec nginx. Nous enquêtons sur les Vernis, mais étaient assez confiant sur le Redis mise en œuvre a été très utile
- +1 pour le Vernis, nous l'utilisons avec beaucoup de succès sur un certain nombre de sites. Le Phoenix Varnishcache extension permet à l'aide de Vernis beaucoup plus facile en prenant soin d'en-têtes de cache, d'invalidation sur les produits sauvegarder, etc.
- Oui, le Vernis est le grand service, il va vous faire économiser beaucoup de douleur. Vernis vous permet de définir vos propres règles de mise en cache, la durée de vie. Il a la grâce de mode, une fois backend n'est pas de répondre au moins une partie de votre site est toujours là. Mais les chouettes fonction si 1000 mêmes demandes viennent du site au même moment, puis vernis n'a qu'une seule demande au serveur d'arrière-plan, et le reste d'entre eux sont en attente, une fois backend renvoie la réponse vernis envoie la réponse à toutes les 1000. L'inconvénient est que vous devez savoir comment le configurer.
- J'ai obtenu une réponse pour mon problème de ta question. +1. Merci..!
- Comment faites-vous pour régler le problème? après de creuser dans le code je viens d'arriver à la même conclusion ... même j'ai changer l'observateur, lié au catalogue de règles, pour nettoyer les seuls qui précise du produit cache la fpc est encore effacé ( lorsque j'enregistre un produit dans le backend )
Vous devez vous connecter pour publier un commentaire.
FPC est en observant les variations de stock, parce que l'intention est d'afficher en rupture de stock pour les produits qui ont été décrémenté à zéro stock. La solution serait de créer un événement d'expédition lorsqu'un produit atteint zéro, plutôt que chaque fois que les changements dans les produits en stock et de réécriture de FPC pour observer cet événement au lieu de l'original.
Une autre méthode serait de seulement invalider les parties de cache portant sur les produits en cours de mise à jour, mais ce serait plutôt architectural important changement.
Vous créer un nouveau mode d'indexation
Mage_Index_Model_Indexer_Abstract , et de créer un nouveau modèle de ressources méthodes de l'api avec des tâches cron
le phoenix de Cache de la Page module efface le produit des pages et des pages de la catégorie, mais laisse quelques zones de l'invalidation du cache de découvert. aussi il ne s'occupe pas de bien avec du contenu dynamique.
peut-être vous devriez vérifier le aoe_static module qui fait un excellent travail de chargement du contenu dynamique par le chargement d'un défaut de mise en page et de rendre les blocs avec un appel ajax. cet appel ajax définit également le cookie pour permettre aux séances.
vous devez être prudent à l'aide de 2 modules dans une jolie région difficile, peut-être vous devriez consulter cette magento open source full page cache
Avoir une lecture de l'article que j'ai écrit sur une Pleine Page en Cache de Magento. Il met en évidence une correction de bug qui rend soudainement l'ensemble de cacher le mécanisme de bon sens!
http://www.excitedcroc.com/article/why-the-magento-full-page-cache-doesnt-expire
Essentiellement il y a un bug dans la façon de Magento utilise le Zend Framework mécanisme de mise en cache.
Le problème est que le Zend bibliothèque les classes de cache et le cache de Magento enterprise classes utilisent un mélange de nul et faux dans leurs fonctions qui produisent de la valeur de durée de vie. Parce que null !== faux, par défaut, une durée de vie de 10 jours est toujours utilisé. Le problème vient de la processRequestResponse fonction dans app/code/core/Enterprise/PageCache/Model/Processor.php. Parce que pas de durée de vie valeur est transmise à l'instance de cache sur enregistrer la valeur par défaut est null.
La modification de la valeur par défaut pour la durée de vie paramètre de la fonction de sauvegarde de app/code/core/Mage/Core/Model/Cache.php va résoudre ce problème. Il suffit de le mettre à false au lieu de null ( l'article lié ci-dessus explique pleinement pourquoi ).
- public function save( $data, $id, $tags = array(), $vie = null )
+ public function save( $data, $id, $tags = array(), $vie = false )