Jean Francois G Posted February 21, 2015 Share Posted February 21, 2015 Prestashop 1.6 permet de mettre le cache smarty en systeme de fichiers, ou en mysql. C'est clair que passer en mysql va faire grossir furieusement la BDD, mais le gain de performance est il à la hauteur de ce désavantage ? Avez vous essayé ? Peut être même avez vous décidez de lisser le cache sur mysql.. Et qu'en pensez vous ? Link to comment Share on other sites More sharing options...
Soufyan Amenzou Posted March 27, 2015 Share Posted March 27, 2015 Bonjour, Personne pour une réponse sur ce sujet ? Merci à vous, Cordialement Link to comment Share on other sites More sharing options...
Jean Francois G Posted April 3, 2015 Author Share Posted April 3, 2015 (edited) y'a pas a dire.. ca bouge ce forum lol ... J'ai remarqué une belle baisse des réponses aux topics depuis quelques temps Edited April 3, 2015 by Jean Francois G (see edit history) Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 Le cache smarty est très bien en système de fichier. Jamais en mysql jamais jamais Link to comment Share on other sites More sharing options...
Jean Francois G Posted April 3, 2015 Author Share Posted April 3, 2015 Alors n'ayant pas de réponse, j'ai basculé le cache en SQL. Je n'ai pas remarqué de différence de temps d'accès ou de vitesse d'affichage. Par contre, l'avantage est que lorsque j'exporte la BD, j'exporte le cache, et c'est un gain de temps énorme pour la restauration par rapport au transfert de tous les fichers cache via FTP. Pourquoi répond tu "jamais jamais jamais" ? Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 (edited) N'importe quoi. Comment le transfert entre 2 processus plus l'indexation plus l'écriture sur le disque pourrait être plus rapide que l'écriture sur le disque brute. Ta base de données vas exploser quelque part dans les prochains jours à cause du volume. Quand à l'export, excuse mais un cache c'est fait pour être purgé donc on ne le transfère pas jamais Et importer un base de 785M c'est un rien plus long qu'une base de 3M ! Transfert FTP et cache? rien compris ! tu ne le transfère pas il sera reconstruit à la demande PS: j'aimerais bien comprendre pourquoi tout ces transfert FTP ? Edited April 3, 2015 by doekia (see edit history) Link to comment Share on other sites More sharing options...
Jean Francois G Posted April 3, 2015 Author Share Posted April 3, 2015 par contre tu peux changer de ton ? (le n'importe quoi est de trop je pense..) Incroyable comme l'agression verbale est courante et les gens ne s'en rendent même plus compte. Enfin bref.. Je transfert mon cache quand je veux faire des tests en local en situation totalement égale à l'installation distante. Si je ne transfert pas le cache , je n'ai pas "exactement' la même situation. Et quelques fois ça fait toute la différence pour trouver un problème. Link to comment Share on other sites More sharing options...
coeos.pro Posted April 3, 2015 Share Posted April 3, 2015 je n'ai pas fait de tests donc je n'ai pas de chiffre à annoncer mais le cache smarty en SQL ne me semble pas une mauvaise idée (faudrait aussi comparer cache smarty en SQL + cache SQL en fichier et cache smarty en fichiers). Par contre on en avait déjà parlé un peu sur le forum, le problème viens des modules fait par des gens qui n'ont strictement aucune notion de "cache" => https://www.prestashop.com/forums/topic/393235-resolu-nouvelle-option-cache-smarty/?do=findComment&comment=1921133 et aussi https://www.prestashop.com/forums/topic/393235-resolu-nouvelle-option-cache-smarty/#entry1921221 Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 1 + 1 + 1 ne sera jamais plus petit que 1 Link to comment Share on other sites More sharing options...
coeos.pro Posted April 3, 2015 Share Posted April 3, 2015 je reformule (pour être sûre de bien me faire comprendre) : faudrait aussi comparer - cache smarty en SQL + cache SQL en fichier et - cache smarty en fichiers Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 Je reformule: SQL recoit des données SQL manipule ces donnes SQL indexes ces donnes SQL écrit sur le système de fichier les données! SQL écrit sur le système de fichier les index! Donc smarty + SQL est par construction plus lent que smarty + fichier Cache SQL en fichier? avec les invalidates a nouveau et sans ton agressif, n'importe quoi! SQL avec son cache mémoire gère très bien celà sur 128GB de mémoire après 2h tout est utilisé par les caches systèmes et SQL et tout est impec. Tous les - j'ai pas d'autres mots désolé - bricolages de cache ci là cache là ici... n'apportent rien pour un réel usage - maintenant si on regarde un shop avec 1 visite par jour c'est autre chose. Mais dès 15 hits secondes - il n'y a pas 2 voies, la bonne et c'est tout. Link to comment Share on other sites More sharing options...
Jean Francois G Posted April 3, 2015 Author Share Posted April 3, 2015 ok, mais je croyais qu'en fait, le cache SQL ne ré-ecrivait pas les données sur le disque. Qu'il envoyait les info directement de SQL au destinataire de la page. Un cache quoi ... Mais si tu me dis que SQL reçoit la requete, traite la requete, envoi le cache sur le systeme de fichier envoi les données au destinataire, la oui c'est pas logique. Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 (edited) SQL c'est une base de données donc du stockage disque. Quand tu demande une page, la partie cache, dès qu'il y a du monde, c'est pratiquement un cache par user, comme il est souvent absent ce cache on le calcule et on l'envoi à SQL qui le stocke, l'indexe pour un usage ultérieur ce que est a plus de 60 jamais le cas dans un shop avec un catalogue un peu nourrit. Quand l'internaute arrive on interroge la table - donc requête select zz where id_cache = xxx en gros Cette requête charge les buffers de la bdd mais comme les buffers on en a besoin pour nos grosses requête catalogue ... soit on invalide un cache sql d'une grosse requête produit soit on invalidate le buffer d'un autre cache. Pour atteindre des performances il n'y a pas de recette magique c'est toujours le choix du plus simple qui donne le meilleur résultat. D'ailleurs si je te dis que j'ai aucun memcache, apc cache xcache sur aucun de mes systèmes ... même ceux à 40 hit/s à l'heure qu'il est . L'erreur est que les mesure sont faites avec le jeu de test ridiculement petit de l'install defaut et sur les même 10 pages ... dans la réalité si tu as 500 internautes tu peux parier qu'ils sont sur 500 pages différentes donc cacher les tpl compilés oui cacher les requêtes non. MySQL a déjà un cache interne, l'OS aussi et leurs heuristiques sont plutôt bien fichu et écrite dans un langage autrement plus performant que PHP. Edited April 3, 2015 by doekia (see edit history) Link to comment Share on other sites More sharing options...
coeos.pro Posted April 3, 2015 Share Posted April 3, 2015 Cache SQL en fichier? avec les invalidates a nouveau et sans ton agressif, n'importe quoi! Si je comprend bien, pour toi le cache SQL par fichier, c'est "n'importe quoi" ? tu n'es pas sérieux ? Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 Ta vision n'est pas entièrement fausse malgré tout mais la problématique c'est l'échelle en fait. Et nous n'avons pas encore regardé le problème de l'insertion du cache dans la bdd avec les locks qui en résultent ... imagine entre les locks des paniers, des stats ou autre et les locks des caches ... on dégringole très très vite coté performance et capacité et ce même sur ces disques SSD ou même ramdisk ... d'ailleurs on utilise très peu les ram disques la ram on la laisse a être géré par le système qui sait très bien l'utiliser et la libérer quand le besoin est là... Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 Si je comprend bien, pour toi le cache SQL par fichier, c'est "n'importe quoi" ? tu n'es pas sérieux ? Si on ne peut plus sérieux... a quoi penses-tu que servent ce genre de paramètre dans le tuning mysql? query_cache_limit query_cache_size read_buffer_size key_buffer_size sort_buffer_size pour ne citer que les plus usités? Link to comment Share on other sites More sharing options...
coeos.pro Posted April 3, 2015 Share Posted April 3, 2015 mais sais tu au moins comment fonctionne le cache SQL par fichier ? Link to comment Share on other sites More sharing options...
doekia Posted April 3, 2015 Share Posted April 3, 2015 oui assez bien ... Link to comment Share on other sites More sharing options...
cockpitinferno Posted May 2, 2016 Share Posted May 2, 2016 ce post est un peu vieux mais j'ai remarqué que en testant le cache en mysql, ca me provoquait une erreur 500 a bout de 3 ou 4 pages visitée. alors que si je reste en fichier, aucun problème. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now