Bonjour à tous,
 
Je suis chargé de refaire l'architecture d'un magazine en ligne qui devra gérer des milliers de visiteurs par jour. De ce fait, des requètes SQL côté client sont trop lourdes et vont vite saturer le serveur. J'ai donc l'idée d'utiliser un cache.  
 
Je pensais réaliser le back-office en XHTML/CSS/PHP avec un serveur SQL (MySQL ou PostGreSQL), au moment où (par exemple ) un rédacteur écrit une news et l'ajoute, cela l'ajoute à la BDD SQL et regénère un fichier XML (ex : News_Avril.xml) qui sert de cache.  
Côté site, le client fait une "requete" sur le cache XML. Le front-office ne serait pas géré en full XML/XSLT (on m'a déconseillé pour une question de référencement et de compatibilité navigateur) mais en PHP/XHTML. Cela vous parait-il viable comme système ? Y a-t-il un moyen plus efficace (tout en restant dans les mêmes langages ^^).
 
Merci d'avance de répondre à ces premières questions (d'autres suivront ^^) et désolé si certaines vous paraissent un peu "naïves".  
 

Tu peux parfaitement utiliser XML/XSLT, à condition que ton XSLT génère un XHTML, et que ça soit fait côté serveur... D'où le problème évident de charge

Imagine un site qui fait au moins 10 000 visiteurs par jour et qui contient plus de 100 000 pages. C'est pour ça que je vois mal comment génerer du XHTML.... Le serveur va exploser non ? ^^

Ou alors on génére le XHTML aussi comme un cache à partir du serveur SQL... Mais ça devient beaucoup moins souple

J'ai fait fuir tout le monde avec mon problème ? ^^

On m'a conseillé d'utiliser memcached. Des avis ?

tu as peur que la base "tombe" (trop de requetes) ou que le serveur HTTP tombe/scotche (trop de requetes http) ou que le serveur tombe (trop de traitements, trop de fichiers ouverts,...).
deja fait une estimation realiste de ce que tu as besoin.
ex: heures de frequentations, traffic max estimé (en Mo), nombre de connections http max.
attention l'exemple suivant est foireux mais te donnera une idée.
par ex:  
10000 pages vues /jours
disons que :
- 1/5 vient hors heures de pointe.
- les heures d'affluences sont 9h-10h , 13h-14h, 18h-19h
- tu peux estimer 8000 pages vues en 3h de temps.
soit 45pages /minute. en moyenne type.
tu double pour avoir un chiffre representatif de la charge "normale" -> 90pages /min
tu quadruple pour avoit une estimation lourde ->180 pages /min -> env 3 pages /sec.
tu connais maintenant ton objectif. un minimum de 3 pages servies/sec
maintenant tu lance un code profiler sur ton appli (sans cache, sans rien, juste l'implementation de base) et tu regarde combien de temps est alloué pour chaque fonction (xml+xsl->xhtml, requete apache, file open/close, connection dbb, requetes).
tu lance un test de charge dessus (opensta par ex.) avec 3/5/10 appels http simultannées par sec.
tu regarde comment ta machine reagit.
et la tu commence a reflechir a ce dont tu as besoin en regardant ou ca rame. si ca rame pas, te prends pas la tete.
si ca rame, regarde quel traitement est le plus lourd en resources.
si c'est requetes, optimise les deja (les preparedstatements servent, les arbres intervallaires aussi), si c'est transfo xsl, pense a generer directement en xhtml.
si c'est requetes http, configure apache.
le top etant evidemment les requetes rapides et leur mutualisation, une generation en xml lors de l'insertion de contenu avec un une cascade sur les autres pages influencées, et la mise en cache des pages xhtml generées. mais ca sert pas toujours. sachant que les mecanismes de cache peuvent vite etre tres lourds a gerer.
une methode simple que j'utilise regulierement mais qui peut faire hurler certains :
- site en dynamique
- je genere le contenu en cache si sa clef n'est pas dans le hashmap global.
- je stocke la clef de la page dans le hashmap global.
- si modification dans le back office, toutes les pages impactées par la modif sont sorties du hashmap.
 
petit defaut : lors de nombreuses requetes, ils peut y avoir beaucoup de fopen, donc pas mal de pointeurs sur fichiers d'ouverts a un moment donné et le hashmap peut devenir assez consequent. et aussi le systeme n'est efficace qu'apres la demande initiale. mais bon, ca marche sur un site qui prends 300-400 requetes http/secondes regulierement alors...

Tu entends quoi par "clef" et "hashmap" ?

si tu gere des pages en dynamique, cela signifie que tu envoie une clef (identifiant unique primaire par exemple) en request
ex: http://forum.hardware.fr/forum2.ph [...] post=88122
la clef c'est "88122"
 
une hashmap c'est une table de hashage qie a des methodes permettant de verifier la presence ou non d'une clef et d'une valeur. en php on peut utiliser un array et la fonction "in_array($value,$array)" pour faire vite.
en gros tu stocke l'id de ta page dans le array en global. lorsqu'une page est demandée tu regarde si elle est ds l'array, si oui tu retourne le fichier genéré associé, si non tu genere le fichier, tu mets l'id dans l'array et tu le renvoie

tu peux aussi directement stocker l'URI de la page comme clef. ca marche aussi et c'est pas beaucoup plus sale.

Bonjour, j'aimerai savoir comment générer un fichier XML à partir d'une base de données SQL ?
Merci

Génerer du XML :
Je ne sais pas si Mysql ou PostGreSQL savent le faire...
Avec Oracle, c'est possible, mais ca rame grâve !
 
Reste à générer le XML en PHP.
Deux méthodes :
Génération sous forme de string. TRES sale, mais rapide.
Générer avec l'aide d'une lib XML (DOM, simpleXML...). Plus propre, mais lent.
 
Pour la gestion du cache :
 
Pour les requête utilisateur, utiliser des URL du genre : http://www.monsite.com/dossier/montagne/pages/125.html
 
De cette manière, si la page existe, pas de passage par PHP.
sinon,  
 Soit utiliser mod_rewrite d'apache pour transformer l'url en quelque chose du genre
 http://www.monsite.com/index.php?d [...] e&page=125
 
 Autre piste, rediriger l'erreur 404 sur un script php qui parse l'URL.
 
Le script PHP lit les infos en base, génère l'XML, applique l'XSL qui va bien et envoie le résultat XHML au client.
Le résultat est aussi stocké dans le fichier /dossier/montagne/pages/125.html pour la prochaine requête client.
 
Pour les rédacteurs, stockage en base, suppression des pages XHTML générées qui font référence à l'article.

Attention, il existe deux versions des packages xml sous Oracle, l'une "deprecated" en Java et l'autre en C, plus rapide. Il faut donc abandonner les packages xml... et xsl... pour les versions dbms_xml... et dbms_xsl...

Merci pour l'info.