C'est un fait établi qu'un site statique basé sur les CSS permet des
économies de bande passante.
Mais pour un site dynamique qu'en est-il ? Je veux dire, avec 3
squelettes statiques de pages et une BDD de, disons 1000 références
(pour un site de commerce par ex) ? Est-ce que le bénéfice est aussi
conséquent quand la génération des pages est dynamique ?
In article (Dans l'article) <418a8ee3$0$15752$, "Peter Pan" wrote (écrivait) :
Pilgrim a écrit : > Qu'en pensez vous ?
Tarif forfaitaire du projet ?
Non, de l'hébergement (Espace + Bande Passante)
mome
Khanh-Dang,
[...] Si on est malin donc, on enregistre cette page dans un cache. Ainsi, le prochain visiteur qui arrive sur la page ne va pas forcer au script PHP appelé à ouvrir une connection à un serveur de base de donnée, interpréter le résultat, générer la page etc... Au lieu de ce long et couteux en performances mécanisme, le script va simplement copier le contenu du cache au navigateur.
as-tu un lien ou des mots-clés car cette fonction que je ne connaissais pas m'intéresse beaucoup et j'aimerais en savoir plus (sur comment activer ce fameux cache côté serveur notamment) !
merci beaucoup !
-- mome
Khanh-Dang,
[...] Si on est malin donc, on enregistre cette page dans
un cache. Ainsi, le prochain visiteur qui arrive sur la page ne va pas
forcer au script PHP appelé à ouvrir une connection à un serveur de base
de donnée, interpréter le résultat, générer la page etc... Au lieu de ce
long et couteux en performances mécanisme, le script va simplement
copier le contenu du cache au navigateur.
as-tu un lien ou des mots-clés car cette fonction que je ne connaissais
pas m'intéresse beaucoup et j'aimerais en savoir plus (sur comment
activer ce fameux cache côté serveur notamment) !
[...] Si on est malin donc, on enregistre cette page dans un cache. Ainsi, le prochain visiteur qui arrive sur la page ne va pas forcer au script PHP appelé à ouvrir une connection à un serveur de base de donnée, interpréter le résultat, générer la page etc... Au lieu de ce long et couteux en performances mécanisme, le script va simplement copier le contenu du cache au navigateur.
as-tu un lien ou des mots-clés car cette fonction que je ne connaissais pas m'intéresse beaucoup et j'aimerais en savoir plus (sur comment activer ce fameux cache côté serveur notamment) !
merci beaucoup !
-- mome
Thibaut Allender
On 4/11/2004 21:47, Pilgrim wrote :
Ha ben nan !!! Souvent la vulgarité désert la sévérité, alors... dis nous ce que tu penses en n'étant pas vulgaire, ça ne ferra que servir ta pensée !
as-tu un lien ou des mots-clés car cette fonction que je ne connaissais pas m'intéresse beaucoup et j'aimerais en savoir plus (sur comment activer ce fameux cache côté serveur notamment) !
je me réponds tout seul http://blog.dreams4net.com/CachezMoiCa
++
mome,
as-tu un lien ou des mots-clés car cette fonction que je ne connaissais
pas m'intéresse beaucoup et j'aimerais en savoir plus (sur comment
activer ce fameux cache côté serveur notamment) !
je me réponds tout seul
http://blog.dreams4net.com/CachezMoiCa
as-tu un lien ou des mots-clés car cette fonction que je ne connaissais pas m'intéresse beaucoup et j'aimerais en savoir plus (sur comment activer ce fameux cache côté serveur notamment) !
je me réponds tout seul http://blog.dreams4net.com/CachezMoiCa
++
Pierre Goiffon
"Khanh-Dang" a écrit dans le message de news:418a8b4d$0$18888$
Pour ma part j'ai compris la question comme tournant autour de l'idée que dynamique implique : aucune page ne peut être cachée. C'est parfois vrai sur certaines pages avec des appels ré-entrants (http://.../tutu?123 et http://.../tutu?007 n'auront pas le mm contenu...), mais c'est quand mm plus une idée reçue qu'autre chose.
Oui, en effet, il y a cache et cache...
Désolé je m'aperçois que j'ais été peu clair. Je parlais du cache par le client (au sens large : navigateur, proxy, serveur de cache, ...), j'avais compris qu'il était question de cela dans le message initial.
Vous avez raison, comme je le soulignais dans un autre message il existe différents moteurs de cache côté serveur pour alléger les traitements. La majorité des moteurs d'inclusion par exemple ne font pas un accès disque pour chaque appel... Et plusieurs moteurs de template disposent d'un moteur de cache. On peut aussi indiquer la possibilité de remplacer son frontal par un anté-proxy... Il y a aussi la compression gzip. Malheureusement plusieurs serveurs ne peuvent pas l'activer sur du contenu généré dynamiquement, ou alors le font à travers des artifices qui au final coutent plus qu'ils n'apportent.
Bref, toutes ces techniques représentent un panel large, mais il est déraisonnable d'écrire comme vous le faites "si on est malin on fera..." : le choix de chacune de ces solutions devra se faire en fonction du besoin, il n'existe pas de réponse globale.
On peut quand même avancer que ce qui coûte le plus cher dans un hébergement, ce n'est pas la ressource CPU - et de loin... Les économies les plus faciles à gagner à court terme sont très souvent situées sur le gain en bande passante, notemment en nettoyant le code (passer aux standards est un très bon moyen) et en se penchant vraiment sur ce qui est envoyé au client comme directives de cache. Ensuite, tout ce qui touche de plus près au serveur et aux traitements eux-même sera forcément plus délicat à mettre en place, car cela touche à l'architecture même du système d'information.
"Khanh-Dang" <kd@fr.invalid> a écrit dans le message de
news:418a8b4d$0$18888$8fcfb975@news.wanadoo.fr
Pour ma part j'ai compris la question comme tournant autour de
l'idée que dynamique implique : aucune page ne peut être cachée.
C'est parfois vrai sur certaines pages avec des appels ré-entrants
(http://.../tutu?123 et http://.../tutu?007 n'auront pas le mm
contenu...), mais c'est quand mm plus une idée reçue qu'autre chose.
Oui, en effet, il y a cache et cache...
Désolé je m'aperçois que j'ais été peu clair. Je parlais du cache par le
client (au sens large : navigateur, proxy, serveur de cache, ...), j'avais
compris qu'il était question de cela dans le message initial.
Vous avez raison, comme je le soulignais dans un autre message il existe
différents moteurs de cache côté serveur pour alléger les traitements. La
majorité des moteurs d'inclusion par exemple ne font pas un accès disque
pour chaque appel... Et plusieurs moteurs de template disposent d'un moteur
de cache. On peut aussi indiquer la possibilité de remplacer son frontal par
un anté-proxy...
Il y a aussi la compression gzip. Malheureusement plusieurs serveurs ne
peuvent pas l'activer sur du contenu généré dynamiquement, ou alors le font
à travers des artifices qui au final coutent plus qu'ils n'apportent.
Bref, toutes ces techniques représentent un panel large, mais il est
déraisonnable d'écrire comme vous le faites "si on est malin on fera..." :
le choix de chacune de ces solutions devra se faire en fonction du besoin,
il n'existe pas de réponse globale.
On peut quand même avancer que ce qui coûte le plus cher dans un
hébergement, ce n'est pas la ressource CPU - et de loin... Les économies les
plus faciles à gagner à court terme sont très souvent situées sur le gain en
bande passante, notemment en nettoyant le code (passer aux standards est un
très bon moyen) et en se penchant vraiment sur ce qui est envoyé au client
comme directives de cache. Ensuite, tout ce qui touche de plus près au
serveur et aux traitements eux-même sera forcément plus délicat à mettre en
place, car cela touche à l'architecture même du système d'information.
"Khanh-Dang" a écrit dans le message de news:418a8b4d$0$18888$
Pour ma part j'ai compris la question comme tournant autour de l'idée que dynamique implique : aucune page ne peut être cachée. C'est parfois vrai sur certaines pages avec des appels ré-entrants (http://.../tutu?123 et http://.../tutu?007 n'auront pas le mm contenu...), mais c'est quand mm plus une idée reçue qu'autre chose.
Oui, en effet, il y a cache et cache...
Désolé je m'aperçois que j'ais été peu clair. Je parlais du cache par le client (au sens large : navigateur, proxy, serveur de cache, ...), j'avais compris qu'il était question de cela dans le message initial.
Vous avez raison, comme je le soulignais dans un autre message il existe différents moteurs de cache côté serveur pour alléger les traitements. La majorité des moteurs d'inclusion par exemple ne font pas un accès disque pour chaque appel... Et plusieurs moteurs de template disposent d'un moteur de cache. On peut aussi indiquer la possibilité de remplacer son frontal par un anté-proxy... Il y a aussi la compression gzip. Malheureusement plusieurs serveurs ne peuvent pas l'activer sur du contenu généré dynamiquement, ou alors le font à travers des artifices qui au final coutent plus qu'ils n'apportent.
Bref, toutes ces techniques représentent un panel large, mais il est déraisonnable d'écrire comme vous le faites "si on est malin on fera..." : le choix de chacune de ces solutions devra se faire en fonction du besoin, il n'existe pas de réponse globale.
On peut quand même avancer que ce qui coûte le plus cher dans un hébergement, ce n'est pas la ressource CPU - et de loin... Les économies les plus faciles à gagner à court terme sont très souvent situées sur le gain en bande passante, notemment en nettoyant le code (passer aux standards est un très bon moyen) et en se penchant vraiment sur ce qui est envoyé au client comme directives de cache. Ensuite, tout ce qui touche de plus près au serveur et aux traitements eux-même sera forcément plus délicat à mettre en place, car cela touche à l'architecture même du système d'information.
