Que pensez-vous de ce systeme de cache?

WRInaute passionné
Bonjour

mon système de cache pour les page web fonctionne pas mal, mais je n'ai pas de recul pour en juger l'efficacité, et j'en appelle à vos avis et conseils:

Voici comment il fonctionne:

- Dans chaque page il y a des sections statiques qui ne changent pas
- Et dans chaque page il y a des sections dynamiques qui changent(par exemple les liens "connexion" déconnexion" en fonction de $_SESSION[]

voici le template:

--------------------
<html>

{cache}head{/cache}

<!-- partie dynamique -->
if($_SESSION['connected']=="OUI"){//affiche liens connect/disconnect}

{cache}contenu{/cache}

{cache}foot{/cache}

</html>
--------------------

chaque section {cache} est mise en cache pour une url donnée

Le désavantage est que pour un site avec 3000 url, cela fait 3000*3 = 9000 fichiers caches

Avez-vous des avis?conseils?
Sauriez-vous faire autrement avec une partie statique et une partie dynamique?

Cordialement
Christophe
 
WRInaute accro
Tu devrais mettre en cache d'après un identifiant unique, si le "foot" est le même dans chaque page, il n'y a pas d'intérêt d'en avoir 3000 copies différentes.

Ta façon de faire est courante.

C'est aussi intéressant de mettre le cache en mémoire: Redis ou Memcached au lieu du disque.
 
WRInaute passionné
Mais ça sert à quoi en terme de performances de mettre en cache des parties qui sont justement statiques... ?!
Le cache, c'est pour qu'une partie dynamique se retrouve statique jusqu'au prochain changement (destruction du cache), pour éviter de refaire des requêtes SQL ou des calculs quand ils ont déjà été faits précédemment...

(je dis ça parce que dans ton message, "contenu" est en rouge comme étant statique, et la partie dynamique en verte, elle, se réexécute à chaque fois que le visiteur charge une page...)

Sinon 9000 fichiers ce n'est pas un problème à partir du moment où ils sont stockés dans des dossiers pour éviter d'avoir (je ne sais plus combien, disons 1000) dans un même dossier pour ne pas faire ralentir leur recherche sur le disque.

Personnellement je ne mets en cache que le résultat des requêtes SQL, parce que concrêtement c'est les accès à la base de données qui sont la plupart du temps responsables des ralentissements, pas l'affichage HTML avec quelques if et else...
 
WRInaute occasionnel
oui c'est bien de mettre en memcache (pas le code) les sessions, d'ailleurs quand on a une ferme de serveurs c'est une obligation pour cause de ssl qui doit être sur une machine qui elle est centralisée et gère les sessions (et le sessions SQL c'est trop lent), sinon ce serait impossible d'avoir des requêtes ssl dispactchées au gré des serveurs de la ferme et des certificats qui exploseraient de partout.
Pour en revenir au cache des pages : pareil, oui il le faut faire des caches de toutes façons quand on fait du cloud truc ou CDN (content delevery network). Sinon faire du CDN ou du cloud n'aurai aucun sens., et de manière logique on ne clone pas les parties dynamiques, juste les parties statiques.

Après les parties dynamiques : sauf dans les zones ecommerce et les fomulaires, c'est assez rare d'en touver dans le web (voir inexistant) - je vois déjà les bla bla bla bla bla m'expliquer le web et les applications web (dont je ne parle pas)

Pour le cas écrit, côté client on s'en balance de mettre un footer en cache sur un site classique, les utilisateurs n'utilisent plus mosaic depuis déjà quelques années, donc les browsers ne rapatrient pas ce qu'ils ont déjà rapatrié une fois.

Pour la toute première page, si vraiment elle met trois plombes à se générer sur le serveur, les CMS récents ont déjà tous leur system automatisé de cache.

Pour résumer : du cache destiné à quoi ? Les sessions si c'est du PHP --> un serveur memcache et même un master - et un backup serveur si le premier crache
La partie serveur : le CMS la gère - OK le code ecrit en dessus pour les CDN sinon inutile
La partie client : on s'en fout le browser gère

Et attention, le cache c'est intéressant si c'est en mémoire. 9000 fichiers sur un disque c'est quedal, mais si le cache sert à accèder à 9000 fichiers sur un disque nommal, aucun intérêt : autant garder des accès bases de données , souvent ca va plus vite que les fichiers sur disque

Du coup on s'aperçoit que tout le monde veut tout mettre en cache, mais que dans la très grande majorité des cas c'est inutile, mal compris et mal utilisé...
 
Dernière édition:
WRInaute passionné
Et attention, le cache c'est intéressant si c'est en mémoire.

Les caches en fichiers sont toujours plus lents que tout le reste, il n'y a rien de plus lent que le lire le disque, mais personnellement je le fais avec un autre objectif que la rapidité : diminuer le nombre de connexions à la base de données, le nombre de connexions simultanées étant limité assez bas sur les serveurs mutualisés.
 
WRInaute passionné
Les caches en fichiers sont toujours plus lents que tout le reste, il n'y a rien de plus lent que le lire le disque, mais personnellement je le fais avec un autre objectif que la rapidité : diminuer le nombre de connexions à la base de données, le nombre de connexions simultanées étant limité assez bas sur les serveurs mutualisés.

que taille (Mo) arrive tu à mettre en cache mémoire?
 
WRInaute passionné
que taille (Mo) arrive tu à mettre en cache mémoire?

Je ne comprends pas la question, j'ai dit que je fais des caches sur disque, donc les fichiers (qui sont des résultats de requêtes) ne font que quelques kilos en général.
Memcached n'étant pas disponible sur les hébergements les moins chers, sinon je l'utiliserais, mais ça reviendrait au même et peu importe qu'au total on mette des dizaines de Mo en mémoire...
 
WRInaute occasionnel
voila une bonne question, qui miterait 12 encyclopédies pour traiter tous les cas.
Je vais encore répondre sur des cas qui n'intéresse personne.
Mais : ca va dépendre du site, de ce qu'il fait, du trafic, du contenu.
Le mieux c'est toujours tout Sauf que ca dépend forcément de ce qu'on a dans tout ce qui est écrit dessus.

De manière générale, tout ce qui est sur disque est pourrav. Mais la mémoire n'est pas extensible.

La bonne idée sur lewoiab, c'est 1 machine = 1 tache
Pour le http truc, a moins d'avoir 500000 de requêtes à la seconde, des front même pourris , du moment qu'ils font que serveur woaib. C'est rare d'avoir besoin de serveur monstrueux. Quelques VM si vraiment on est survisité.
La BD : catastophe. A mettre sur un serveur fusée, avec de la ram, dela ram, de la ram et de la ram
Et je parle de la BD qui génère les pages woaib parce que tout ce qui est données clients, ce ne doit pas être live accesible..;
Si on a pas dela ram, de la ram, de la ram, c'est toujours moins grave de déporter quand même la db sur un autre endroit que le serveur woaib (d'ailleurs aucun hébergeur ne met la db au même endroit que le servur wouaib. Ils ne sont pas fous). Autre endroit bien sur qui doit être accessible dans le même réseau et a grande vitesse. exit les accès diques (mem cahce c'est juste un choisx dans php.ini)

La réponse à la question est donc : le maximum en ram. Si on a qu'un seul serveur : on le coupe en VM. On met le paquet dans la VM de la DB.
Si on accès a rien, on ne fait rien
 
Dernière édition:
WRInaute impliqué
Bonjour,
je n'ai jamais compris le système de cache, sa fonction etc.. Bon, après tout, c'est normal, je ne code pas donc tout ça m'échappe.
Il me faudrait un cours comme si j'avais 8 ans.
 
WRInaute occasionnel
le cache c'est on ne peut plus simple. On redemande en permanence les mêmes choses dans le wouiab. Et ces mêmes choses peuvent parfois prendre du temps a générer. Donc on stocke la réponse dans un endroit, le cache et on retourne la réponse déjà calculée
Exemple de 8 ans . Tu demande a ton serveur 2+2 il calcule 4 et comme tu vas lui redemander 2+2. il ne va pas le recalculer, il va te répondre 4 et au miracle le 4 est dans sa mémoire cache.
Lui il gagne en temps de calcul et toi tu auras la réponse plus vite
 
WRInaute impliqué
Ok merci @rollback mais où se trouve le cache ?

Sur un PC, dans un navigateur, sur un serveur,dans un logiciel...?

En gros, comment met-on en oeuvre un cache?

Là, tu m'a répondu à quoi il servait mais tu ne m'a pas dit ce que c'est concrètement. Si ça se code, si c'est sur tous les sites internet, si il y a cache et cache.( un bon cache et un mauvais cache)..

Tu n'es pas obligé de me répondre car pour moi, il faudrait partir de zéro.
 
WRInaute occasionnel
du cache tu peux en mettre sur toute la chaine du wouaib. En plus tu peux ajouter des trucs partout dans la chaine du woaib, des proxys qui mettent en cache les sites... ca fait du monde
Déjà ton browser dait du cache.
 
WRInaute occasionnel
du cache tu peux en mettre sur toute la chaine du wouaib. En plus tu peux ajouter des trucs partout dans la chaine du woaib, des proxys qui mettent en cache les sites... ca fait du monde
Déjà ton browser dait du cache.
Tu veux comprendre : vide ton browser ,prends wrireshark et regarde la différence de ce qui passe quand tu vas sur un site, puis la page suivante. Vide ton browser et va directement sur la page suivante.

Si c'est trop compliqué wireshark, prend fiddler4 et fait pareil

Donc déjà tu verras quand faisant rien, déjà ton browser cache

Pour la partie serveur, si tu as 3 visiteurs par jour, on s'en fout du cache
Si tu en a 10000 et qu'en plus ils reste 2 minutes sur une connexion, la seule gestion des sessions va embourber ton serveur wouaib qui ne pourra même plus répondre à plus rien.
Donc on met dur des serveur autres que le web la gestion des sessions..

-------------
Et la patatra https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
comme on s'en fout du cache : un peu de DDOS :

tout protocole qui génère en sortie plus de données qu'en entrée est source de ddos par amplification

le principe est simple et immensément reproductible : on envoie une requête courte via un protocole.
Dans cette requête, on bricole les en-têtes pour faire croire que c'est la machine à faire tomber qui a envoyer la demande. En retour, la machine à faire tomber reçoit le retour plus gros.
UDP, c'est cool, le paquet d'envoi est de petite taille
Donc c'est cool pour le DDOS, tous les protocol UDP vers des trucs publics = les serveurs DNS, les serveur memecache
Les personnes qui font du ddos, recherchent les meilleurs taux d’amplifications
Ca va très vite, sur du DNS c'est du *10 Donc en contrôlant 1000 machines déjà ils envoient 10000
Et les nombre de serveurs dans les mains des personnes malveillantes, c'est pharaonique. Peut être le votre sans même vous en douter.
Un serveur dans les mains des personnes malveillantes peuvent envoyer des nombres colossaux de paquet amplifiés qui vont aller embêter un system * 10 * un nombre colossal de serveur dans les mains de personens malveillantes. A l'arrivée, des attaques DDOS ..

----------

Pour le reste, le cache, tu fais comme tout le monde, tu coches chaque fois que tu vois marquer cache, mis en cache... Après tu dis que t'as gagné 20 secondes sur le téléchargement de ton site, 200 places dans google et tout le monde est content surtout ton boss ou ton client (si tes courbes de trafic vont vers le bas, impriment les en miroir)
 
WRInaute occasionnel
Donc le cache, on s'en balance (loadbalancer) et si on n'a pas au moins un serveur à gérer, ça veut dire que le cache n'a aucun intérêt réel, et si on a un serveur à gérer ca veut dire qu'en général sait en quoi consite la gestion du cache à tout endroit de la chaine du wouaib
 
Discussions similaires
Haut