Jump to content

Cache systeme de fichier ou cache par Mysql.. Lequel choisir ?


Recommended Posts

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

  • 1 month later...

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

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 by doekia (see edit history)
Link to comment
Share on other sites

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

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

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

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

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 by doekia (see edit history)
Link to comment
Share on other sites

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

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

  • 1 year later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...