Bonsoir à tous !
 
Je me pose depuis quelques jours une question existentielle sur le fonctionnement du cache du site suivant :  
http://www.arenajunkies.com/rankings/
 
Pourquoi ce site ?  
 
Parce que, puisque l'on peut sélectionner la page que l'on souhaite afficher selon une dizaine de paramètres, et qu'il y a grosso modo 10 choix possibles par paramètres, cela fait du ... 10^10 pages ...
 
Aussi, je me demande comment est ce que le fonctionnement du cache d'un tel site peut il se faire ?
 
Dans un tel cas, doit on utiliser un cache au risque de saturer son espace disque (parce que bon même à 1octet la page, ca fait 10go de cache ...) (j'imagine bien la tête d'un robot mal fait qui vient crawler le site ... ) ?
 
Y a-t-il une autre technique pour générer un cache sans saturer son espace disque ?
 
Merci d'avance

Houlalalala  

http://fr.wikipedia.org/wiki/Page_Web_dynamique  

Obvious troll

Oui, je me rends compte que la manière avec laquelle j'ai posé ma question peut la faire passer pour un troll...
 
Oui oui je sais comment il génère les pages !
 
Ce que je dis, c'est que si ils veulent créer un cache pour éviter d'avoir à reconstruire la page à chaque appel, comment font-ils (puisqu'il peut y avoir énormément de pages sur le site) ?

Un cache ne conserve qu'une partie des pages potentielles: celles qui ont ete demandees et qui n'ont pas ete sorties du cache pour une raison ou une autre.  Et une des raisons pour lesquelles on fait sortir des pages d'un cache, c'est parce que sinon le cache prendrait trop de place.

- le cache est généré 'on-demand'. si personne demande la page y'a pas de cache.
- le cache a un ttl donc on efface les fichiers non demandés depuis X minutes/heures/jours/... ou les fichiers dont la derniere demande est la plus ancienne dans le cas d'un allocated size
 
un petit tour du coté de apache/mod_disk_cache + htcacheclean devrait t'expliquer tout ca.
 

Bon et accéssoirement, si ton site devait effectivement avoir besoin de 10^10 pages de cache (ce dont je doute fortement), au prix du téra actuel ça ferait même pas 100 balles d'investissement hein ....

et s'ils utilisaient une base de données pour stocker les informations ...

ils utilisent certainement une dbb mais l'overhead sur les ouvertures de connection et la longueur des requetes + temps  de traitement du code php prendra forcement plus de temps que la lecture de la meme page en cache disque et l'envoi en stream vers l'output.
on peut mitiger ca avec des cachedqueries/prepared statement puis avec de l'opcode memcache mais ca ne suffira probablement pas si les données changent souvent. => cache disque

Memcached ?

 
Bah il y a plein d'options qu'on peut utiliser. Le tout est de savoir ce qu'on a vraiment comme cahier des charges..

je crois que tu rate la principale limite d'un cache en général,, et particulièrement d'un cache aussi lent qu'un disque : ça n'aime pas les données qui changent

non non je sais parfaitement comment marche mod_disk_cache et le cache management, je te rassure on est d'accord sur un point, le cache disque n'est pas "rapide", maintenant le cache n'a aucun probleme a gérer des données qui changent régulierement, c'est juste au dev de définir le TTL.
 
dans ce cas particuler la *limitation* du cache disque est un avantage, on peut pinailler sur cache disque/cache memoire mais a l'usage je prefere le cache disque utilisé sur un FS rapide.
 
la notion de "souvent" change en fonction des sites, il me semble pas que sur le site réferencé présente des données critique temps réel avec obligation de resultats exacts.
 
dans ce cas de figure on utilise le cache parce qu'on sait qu'il va fournir de la data meme si elle est obsolete, on utilise la *limitation* pour palier a une surcharge possible en dbb/cpu
 
le nombre de requete possibles etant de complexité exponentielle il est quasiment impossible de profiter des prepared statements ainsi que du cache dbb, a moins d'avoir identifié des requetes récurrentes auquel cas seules ces dernieres seraient cachées, pour le reste ce sera du miss dans la dbb et du full parse de clefs/index.
 
les trucs d'opcode caching c'est de l'optim applicative donc ca ne touche que lors de l'execution de code, pas pertinent car n'affecte pas directement les data/calculs
 
il est largement plus rentable d'avoir un serveur qui fourni des données meme périmées depuis 5mn qu'une erreur 500 ou un too many connections.
 
au passage, si la dbb fait miss dans son cache memoire, devinez d'ou elle lit , bingo! depuis le disque! sauf qu'au lieu de faire une lecture et d'envoyer sur le stdout elle envoit a du code qui doit etre executé avant d'envoyer au stdout.
 
 
 

donc selon toi il est impossible de cacher suffisament de requetes pour que ca vaille le coup , mais tu peux cacher l'ensemble des ficheirs ?  
 
a noter que lorsque le cache d'une bdd rate, la regeneration d'une page peut ne pas significativement plus longue que lorsqu'il faut retrouver une page, ou un ensemble de page parmis plusieurs  dizaine de millions

avec un cache dbb de X Mo tu peux cacher quelques index (ca depends evidemment de la taille de ta dbb, ici, elle me semble importante). a savoir que ce cache ne peut pas etre extensible et prend des ressources importantes en statique (memoire) ainsi qu'en dynamique (cpu) meme si ca hit.
 
un cache disque tu peux facilement allouer 3Go de cache pour les fichier html de rendu final et avec un file systeme performant le fetch du fichier est rapide, suffisament pour compenser le temps que prendrais une requete a etre executée si il y a deja dans le pool.
 
le principe c'est de lisser l'utilisation des ressources et eviter les deadlocks et garantir une QoS constante, les applis qui bouffent 100% de cpu toutes les 5mn et 0 le reste du temps c'est rigolo mais en prod c'est parfois pas intéressant.
 
une requete en cache miss *peut* ne pas prendre beaucoup plus de temps, mais elle peut aussi et plus souvent en prendre plus. ca depends de la compléxité des requetes.
 
disons qu'un site avec une dbb de ~1Go, des tables de 150000 entrées, liées par des clefs composites et ou index (pas primaires) necessitant l'appel a 6 tables distinctes en moyenne a chaque requete et des conditions complexes. impossible a dénormaliser et servant 50000 pages/jour avec 3 queries par page en moyenne, un site correct (pas énorme) en gros
 
tu lances des tests de charge, par exemple un httperf (genre 200 requetes, 50 connections concurrentes ) avec et sans cache tu me donnes le résultat.  
 
en fait le résultat je le connais, sans cache, la dbb et le cpu serrent et rament a mort (cache dbb de 128Mo...), ca sort une page en 3.1s, avec cache disque les pages sortent en 14ms.
 
perso, je fait vite la différence

donc de 10 milliards de pages, tu passes a 3 Go  
pour les 10 000 000 000 de pages, ça fait au minimum dans les 5 a 10 To de stockage rapide  
 
ennsuite tu ajoutes que les requêtes a la bdd sont mal optimisées ( 6 jointures, condition complexes non précalculable ) , avec un cache ridicule  :128 Mo  
 
Soit un minimum honnete, compare ce qui est comparable : si tu peux cacher le fichiers, tu peux aussi dé normaliser ta base  
 
tip , tu n'es pas le seul a bosser avec des tables de taille moyenne .

10 milliards de page possibles != 10 milliards de pages a fournir à un moment donné, je pense que tu es de mauvaise foi ou que tu es borné
le principe du cache c'est de ne garder les pages que pendant une durée donnée.
 
[edit]
je te rappelle que le cache s'applique APRES l'execution et les acces DBB de la requete initiale.
le seul overhead est en écriture de fichier initial.
[/edit]
 
le cache de 128Mo est peut etre ridicule comparé a la taille de la db mais les tests avec 512 Mo et + n'ont pas apporté de gain significatif. (128Mo c'est deja ~13% de la taille de la base, ca doit donc couvrir déja une bonne partie des index)
 
les requetes sont basées sur une base imposée en read-only, pas le droit de rajouter des clefs, impossible de denormaliser car archi historique du client et en mode slave.
 
6 jointures c'est la plaie a dénormaliser et ca va alourdir enormement la base, surtout que ce ne sont souvent des jointures 1,n . mais bon, on a meme pas le droit d'essayer donc... si on pouvait on arriverait avec des ratio index/data tellement important que l'index servirait a rien.
 
j'essaye juste de comprendre pourquoi tu tentes absolument de me faire croire que la dbb en live c'est forcement la meilleure solution a tous les problèmes.
 
je suis completement honnete et je te donnes des metriques de prod, fais en autant et on en reparle.
 
je suis certainement pas le seul a bosser sur des bases moyenne, je te donne juste des métriques plutot que parler dans le vent et je suis certainement pas le seul a privilégier le cache disque a du brute force dbb/cpu, sinon c'est facile, "cpu plus puissant", "passez en raid de SSD", "plus de ram"...
 
maintenant la partie optim code, optim dbb c'est obligatoire. mais quand on ne peut pas et ben on ne fait pas.
 
si tu bosses sur des projs moyens tu sais comme moi qu'on choisit une solution en fonction du ratio cout/gain. enclencher le cache disque sur un site fait correctemment c'est 1-2h de travail max en dev pour un gain dans mon cas de 230x. une dénormalisation c'est pas le meme cout et c'est pas forcement le meme gain.
 
"Soit un minimum honnete, compare ce qui est comparable"
je compare, et pour l'instant je persiste

donc en fait, tu donnes une reponse et  une justification qui n' ont  rien a voir avec la question d'origine  
 
alors oui , dans ton cas, ou il n'y a rien d'autre a faire, le cache disque est une des meilleure solution  
 
 
mais bon, le coup de la base read only, avec juste ce qu'il faut d ehit pour necessiter un gros cache, mais l'interdiction d'utiliser toutes les autres tehniques d'optimisation, c'est *peut etre* un poil spécifique,non?  
 
Tu veux quoi comme métrique ? que je desactive apc/ les index sur mes tables ? ça  apporterai quoi d'autre qu'un autre cas particulier ? Je travaille avec des données dont le ttl est de l'ordre  de la minute. Inutile d'ecrire quoi que ce soit sur le disque

la question d'origine c'est un site ou il y a enormement de stats resultant de croisement de tables (et certainement des relation circulaires)
arena/guild/player/bracket(indexes)/team(indexes)
etant donné que les stats sont le résultat d'un calcul il me semble cohérent de cacher ses valeurs plutot que de les calculer a chaque fois.
 
dans le cas d'une denormalisation cela signifie qu'on devrait updater pas mal de tables/lignes a chaque insert en plus du calcul, on gagne en flexibilité mais pour un gain final pas forcément intéressant et un travail plus complexe en terme d'intégrité de données (updates concurrents et nécéssité de prostock => deadlock?)
 
le cache disque est le plus rentable a ce petit jeu, on peut aussi mettre un cache memoire mais il y a un (petit) overhead lié au chargement en  memoire puis envoi au kernel buffer pour effectuer un sendfile(), le cache disque utilise directement un sendfile() et me semble un meilleur compromis, il y a des threads tres interessants dans le forum apache sur ce point.
 
mon exemple est un cas limite mais nous a forcé a verifier la faisabilité et le cout (en implementation et pour la machine) d'une denormalisation et simplification des requetes. avant meme que la contrainte de r-o nous soit communiqué la balance a fortement penché sur du cache disque et nous avions préparé le code en conséquence. s'il advennait que nous ayons le droit de faire modifier le schema de la dbb master cela serait un autre plus mais ne jouerais pas autant et ne prendrait pas 2h a réaliser (et du point de vue du client si ca se voit pas c'est de l'argent jeté par les fenetres)
 
je ne dis pas que le cache disque remplace une bonne optim, je dis qu'il permet un gain qualitatif important pour un cout réduit et que pour le site ciblé par ce thread me semble la solution la plus plausible.
 
pour les métriques pas besoin de desactiver APC on l'utilise aussi ainsi que quelques tables temporaires dans une base locale afin de  fluidifier certaines requetes récurrentes. par contre tu peux tester d'enclencher un cache disque avec un ttl de 60secondes et faire un comparatif httperf avant/apres.
 
apres le gain depend du nombre de pages identiques affichées pendant ces 60secondes, une homepage par exemple a tout a y gagner.
 
[edit]
les bases avec schema fermé c'est pas la premiere fois que je tombe dessus.
au moins 3 clients ces 6 dernieres années m'ont fait le coup. des qu'on rentre dans de la gestion de stocks/produits/logistique multi-centres ou du middleware en distribué on a de fortes chances de se cogner ces problématiques car le dba il va pas nous laisser la main sur son joujou
[/edit]

et s'il avait plusieurs serveurs pour gérer ça, genre un cluster avec une bdd fixe pour modifier ou créer de nouvelles entrée, et des réplications de bdd pour les select ?
Edit :
plus un serveur pour gérer les redirections de requêtes et éventuellement faire office de serveur APACHE / PHP.
 
ça marcherait ca aussi non

Si tu ne fais les modifs que dans une base, les autres ne sont pas au courant et fournissent donc des données "périmées".
Sinon, faut faire la modif partout ... et on en revient au même problème  

ben non le principe de la synchronisation des tables, tu modifie une base, ensuite la modification de réplique sur les autres base dans un labs de temps très court.
il font chez google avec leurs système de fichiers réparti sur X milliers de serveurs ?? ou facebook ?
 
je ne me suis pas fait comprendre alors, j'ai du employer le mauvais termes, c'est cluster qu'il faut retenir