Auteur Sujet: Mod_gzip  (Lu 3186 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne MaximuS

  • Expert
  • ****
  • Messages: 577
    • The Caribbean Weblog
Mod_gzip
« Réponse #15 le: 14 octobre 2003 à 19:42:26 »
Impressionant !!!

faut ke tu nous montre comment tu fais ça , au moins que tu donnes des sources /LINK/

je vouslais savoir aussi (c le + important) si l'optimisation prenait plusde temps à programmer que la programmation du site en elle même... :rolleyes:  

Hors ligne Dash

  • Débutant
  • *
  • Messages: 61
    • http://www.phpnet.org/forum/index.php?showuser=454
Mod_gzip
« Réponse #16 le: 17 octobre 2003 à 11:42:03 »
Voici les grandes lignes de ma methode

Je pars de 3 principes:
1°/ une page dite "dynamique" peut souvent etre consideree comme statique. Au moins un *certain* laps de temps.
2°/ une page dynamique est constitues de parties statiques.
3°/ traiter une page statique (HTML) est beaucoup plus rapide que de traiter une page "dynamique" (PHP).

D'ou l'interet d'utiliser des systemes de cache en cascade : des caches PHP/HTML/JS/CSS et un de requetes SQL.

Cache PHP/HTML
---------------------------
- Lorsqu'un utilisateur demande une page. On verifie si l'integralite de la page existe deja dans le cache "final". Si oui, il suffit de lui retourner le contenu du cache tel quel.
- Dans le cas contraire, il faut assembler les differents "blocs" qui constituent le document demande : marges, pied de page, css... Certains de ces blocs sont redondants, les mettre en cache permet de diminuer le nombre de traitements repetitif (fichiers d'inclusion, requetes SQL, boucles, parsing, etc.) lorsque ceux ci-sont suffisament importants.
- Enfin, personellement j'utilise un moteur de template (celui de phpbb, disponible en sous license GNU/GPL) pour separer le code HTML du code PHP. Ce genre de moteur est forcement gourmand en CPU. D'ou l'interet d'utiliser un cache de code *compile* avec ce genre de moteur.

Ce qui donne donc 3 cache, disposes en cascade. Plus on "descend" dans ce systeme, plus le nombre de fichiers d'inclusion augmente, ainsi que les traitements a effectuer (boucles, tests, parsing, requetes eventuelles, etc.) l'ideal est donc de mettre en cache tout ce qui est susceptible d'etre utilise frequemment : pages, feuilles de style, fichiers JS generes a la volee, etc.


Cache SQL
-----------------
Beaucoup de requetes sont redondantes. Ex: la liste des moderateurs sur un forum, un calendrier associatif, etc. Pourquoi faire systematiquement des requetes alors que ces donnees ne sont pas modifiees on continu ? Le principe du cache consiste a recuperer le resultat des requetes une seule fois et de stocker ces donnees dans un fichier php dont l'acces sera beaucoup plus rapide.


Au final une fois le systeme de cache installe et convenablement regle, il vit sa vie; il cree les sous-repertoires necessaires, genere ses fichiers quand il en a besoin, les supprime quand il estime qu'ils ne sont plus valide, etc. Et comme je suis feignant, je me suis arrange pour que les meme librairies gerent aussi bien les caches HTML, SQL, RSS, RDF, XML. Puisque le principe reste le meme. Tout l'art consiste a gerer les parametres des caches : noms de fichiers, duree de validation, controle du volume du cache, etc.

Illustration
./backend/
./backend/rss
./backend/rdf
./backend/xml
./cache/
./cache/sql
./cache/js
./cache/template{id}/
./cache/template{id}/html_final
./cache/template{id}/html_blocks
./cache/template{id}/php_code



Transfert Serveur -> Client
-------------------------------------
Si la page a renvoyer vers le client presente un Etag identique a celui present dans les headers du navigateur, on renvoit simplement un code 304 . Inutile de lui transferer le document - meme en gzip - puisqu'il possede exactement le meme sur sa machine. Dans le cas contraire, on peut envisager de lui transmettre le document sous compression gzip. Pourquoi pas.


A tout cela il faut encore ajouter d'autres "trucs" d'optimisation : coder en rendant php hypersensible (variables non declaree, etc. - toute erreur, meme minime, ralenti le code et est susceptible de presenter une faille), bien reflechir a la structure de ses tables SQL, faire du HTML propre, mettre du JS dans ses formulaire pour soulager le serveur, etc...


Citer
je vouslais savoir aussi (c le + important) si l'optimisation prenait plusde temps à programmer que la programmation du site en elle même... :rolleyes:

Pour ce qui me concerne, le systeme que j'ai developpe n'est pas parfait, mais deja grandement suffisant. Cette optimisation du site fait partie integrante du cahier des charges et donc se reflechit avant meme la programmation du site. Ca prend du temps. Mais c'est un investissement a faire. Pour moi, c'est meme un parametre important dans le choix de l'hebergeur ainsi que des moyens techniques (quels portails utiliser ? faut-il prevoir un script de cache ? etc.). A quoi ca sert de creer un site si du point de vue performance on produit quelque chose d'inutilisable dans la pratique ? Lorsque je vois un site avec plus de 50 requetes effectives sur une page d'accueil et plus de 120 requetes effectives sur une page de liens, j'ai plutot tendance a croire que ce site est objectivement loin d'etre adapte a phpnet.org, par exemple. Pas vous ?

Sur mes forums ipb j'ai tente la demarche inverse : adapter des caches en fonction du site. Il a fallu analyser le code, comprendre les requetes SQL, souvent les reformuler pour en sortir des requetes generiques susceptibles d'etre mis en cache, etc. Ca a quand meme demande un bon gros week-end. Dans le cas des forums ipb il etait inutile de faire un cache HTML. IPB n'utilise pas de moteur de template complique et l'affichage se fait simplement via de simples fonctions. utiliser un cache HTML aurait ete plus lourd qu'autre chose.

Bref, tout peut etre optimise - pour le confort des utilisateurs et pour soulager le serveur - mais chaque cas doit etre traite separement. Tout comme la compression gzip n'est pas une solution universelle.

C'est un long post, mais j'espere que ca repond a vos questions.

quelques references :
- moteur de template: forums phpbb, smarty ...
- etags: jrcache...
- cache SQL: [DEV] cache system...
- PHP avance, Arnaud GADAL, Micro Application, col. e-poche (http://www.microapp.com)
- google et tous les ouvrages disponibles en librairie ou sur amazon.com
« Modifié: 17 octobre 2003 à 13:07:52 par Dash »

Hors ligne Gorn`Nova

  • Habitué
  • **
  • Messages: 140
    • http://www.damnes.com
Mod_gzip
« Réponse #17 le: 17 octobre 2003 à 13:21:05 »
alors la, chapeau...

je sens que je vais passer un long week end moi :D (enfin si j'arrive a faire mes modifs sans rien planter :rolleyes:)
mais comme dirait quelqu'un dont j'ai oublié le nom : "No pain, no gain !"    



Que celui qui n'a jamais bu me jette la première bière !
¤Divide By Cucumber Error. Please Reinstall Universe And Reboot¤

vetofish

  • Invité
Mod_gzip
« Réponse #18 le: 17 octobre 2003 à 13:36:14 »
J'ai aussi un système de cache PHP/SQL pour les visiteurs de mon site (pas les membres).

Quand une page est affichée, le code source est mis en cache (pendant x minutes, configurable). Si un autre visiteur demande la même page, alors c'est le fichier mis en cache qui est demandé ... Bilan : 0 requete SQL !!!

Je n'ai pas de mérite, j'utilise un CMS qui dispose de cette fonction.  :rolleyes:

Par contre pour le cache SQL, alors là, ça m'intéresse aussi ...

Hors ligne Dash

  • Débutant
  • *
  • Messages: 61
    • http://www.phpnet.org/forum/index.php?showuser=454
Mod_gzip
« Réponse #19 le: 21 octobre 2003 à 11:47:12 »
Faire un cache de db est la partie la plus interessante puisqu'il est alors relativement facile de faire des variantes sur le format du cache. Pour des exportations de donnees par exemple : rss, rdf, xml, csv, etc.

Autre chose concernant les ressources d'optimisation.
Etude des principales solutions d'optimisation d'un serveur Web Apache/PHP/MySQL
article du JDNet

Ca date un peu mais ca reste interessant a lire. Au moins pour la methodologie de travail.
Il faudrait appliquer des benchmarks au moins similaires pour determiner les avantages de tel ou tel autre solution d'optimisation (gzip, caches, etc).
Et qui sait, peut-etre envisager alors d'installer (ou de proposer) une nouvelle application sur les serveurs de phpnet ?  ^_^