GZIP Optimiser la vitesse d'un site?

tryan · 9 Avril 2010

Bonjour,

J'essaye d'optimiser la vitesse d'affichage d'un site en utilisant GZIP. Je vous prévient tout de suite, je suis une grosse brêle dans ce domaine et je fais des testes de codes que je trouve sur le web.

Mon serveur, 1&1 mutualisé (pack perso).
Version de php 4.4.9.

Mes testes se font sur un sous domaine.

Code du fichier .htaccess à la racine du site :

Code:

AddType x-mapp-php4 .php
AddHandler x-mapp-php4 .php

Je créé un new fichier nommé php.ini contenant la ligne suivante et également placé à la racine du site :

Code:

<?
zlib.output_compression = true
?>

Résultat :
Avant : 5.45 KB
Après : 1.86 KB
Taux de gains en % : 65.87%

Teste effectué sur le site http://www.whatsmyip.org/http_compression/ .

Comme dit plus haut, je suis un neuneu dans le domaine et j'aimerais bien savoir :
-Si la manip. vous semble correcte?
-Ce que ça fait exactement?

Merci de vos lumières :wink:

medium69 · 9 Avril 2010

Pour les navigateurs le supportant (presque tous les récent), cela permet de leur envoyé les données de la page au format compressé. donc gain de temps pour l'affichage.

petitchevalroux · 9 Avril 2010

medium69 a dit:
donc gain de temps pour l'affichage.

Gain de temps au téléchargement pour être plus précis.

Si je comprend pas trop ta manip mais je sais ce qu'elle fait : Elle indique à php de compresser les sorties de php en gzip.

Ce que j'ai du mal a comprendre c'est le coup du php.ini avec des balises php dedans et une variable de type .ini ... mais bon 1and1 ça fait longtemps que j'ai arrêté d'essayer de comprendre :mrgreen:

L'essentiel c'est de vérifier que tu as bien l'entête "Content-Encoding: gzip" quand tu demandes un fichier php, si c'est le cas ça fonctionne

dorian53 · 9 Avril 2010

tryan a dit:
Bonjour,

J'essaye d'optimiser la vitesse d'affichage d'un site en utilisant GZIP.

La question reste toujours la même à ce sujet.

Une fois les données reçu, le temps d'affichage est lié au navigateur. Et ce temps à mon avis il n'est pas pris (ne sera pas pris) en compte par les moteurs.

Après, est-ce que le temps de compression côté serveur permet de gagner du temps sur la transmission d'un volume de données un peu plus lourd sans compression ?

temps de compression + temps de transfert des données compressées = ?
non compression + temps de transfert données lourd = ?

petitchevalroux · 9 Avril 2010

dorian53 a dit:
Une fois les données reçu, le temps d'affichage est lié au navigateur. Et ce temps à mon avis il n'est pas pris (ne sera pas pris) en compte par les moteurs.

Tu oublies que google commence à rendre le js donc pourquoi pas le HTML un jour ou l'autre

dorian53 a dit:
Après, est-ce que le temps de compression côté serveur permet de gagner du temps sur la transmission d'un volume de données un peu plus lourd sans compression ?

Clairement tous les tests que j'ai fait disent que le gzip ultra rapide. Je l'utilise non seulement pour mes pages html mais aussi pour mon le cache des objets en mémoire tellement c'est rapide.

Je vais vous faire un petit bench si vous voulez

tryan · 9 Avril 2010

Merci de vos réponses :mrgreen:

petitchevalroux a dit:
medium69 a dit:

donc gain de temps pour l'affichage.

Cliquez pour agrandir...

Ce que j'ai du mal a comprendre c'est le coup du php.ini avec des balises php dedans et une variable de type .ini ...

L'essentiel c'est de vérifier que tu as bien l'entête "Content-Encoding: gzip" quand tu demandes un fichier php, si c'est le cas ça fonctionne

Pour le php.ini, j'ai bêtement suivit un tuto trouvé sur le net (mode neuneu ^^).

L'entête renvoyé sur le sous domaine est le suivant :

Code:

Date: Fri, 09 Apr 2010 16:18:16 GMT
Server: Apache
Content-Encoding: gzip
Vary: Accept-Encoding
X-Powered-By: PHP/4.4.9
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

200 OK

Visiblement, ça semble bon ( je crois..).

dorian53, tes remarques me laisse perplexe quand à la réelle utilité de "gziper" ?? Si l'internaute à un affichage plus rapide (merci medium69

), c'est toujours ça de gagné ..non ?

finstreet · 9 Avril 2010

Voici ce que ca fait :

http://www.edubourse.com/blog/index.php/2010/01/22/120-google-page-spe ... sion-gzip-

tryan · 9 Avril 2010

Merci finstreet, vue comme ça, c'est plus parlant

.
J'ai été lire ton "poste" et comme je l'avais déjà fait, j'ai fait un phpinfo () mais contrairement à toi, je ne trouve pas la présence de GZip (ou alors j'ai la vue qui baisse).
Par contre j'ai :

Code:

zlib.output_compression	On	On
zlib.output_compression_level	-1	-1
zlib.output_handler	no value	no value

Cela à un rapport ou pas ?

Dans tout les cas, je trouve que les différences de manip. d'un serveur à l'autre, d'un tuto à l'autre sont vraiment super chiant .. c'est la jungle pour trouver exactement ce que l'on doit faire.

finstreet, dans tes graphes et l'utilisation de GZip, est ce que ça compresse également tout ce qui js, css, image et compagnie ou c'est encore d'autres manip. à effectuer?

petitchevalroux · 9 Avril 2010

Bon ben je viens de faire un petit test sur un rps depuis un autre serveur et c'est assez stupéfiant ( Requests per second est le plus important plus c'est grand plus ça envoie :mrgreen

.
Avec GZ serveur=>rps:

Code:

Concurrency Level:      10
Time taken for tests:   30.566 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      31170000 bytes
HTML transferred:       30235000 bytes
Requests per second:    163.58 [#/sec] (mean)
Time per request:       61.132 [ms] (mean)
Time per request:       6.113 [ms] (mean, across all concurrent requests)
Transfer rate:          995.85 [Kbytes/sec] received

Sans GZ serveur=>rps :

Code:

Concurrency Level:      10
Time taken for tests:   22.459 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      100950000 bytes
HTML transferred:       100245000 bytes
Requests per second:    222.63 [#/sec] (mean)
Time per request:       44.917 [ms] (mean)
Time per request:       4.492 [ms] (mean, across all concurrent requests)
Transfer rate:          4389.61 [Kbytes/sec] received

Avec GZ freebox=>rps :

Code:

Concurrency Level:      10
Time taken for tests:   7.882 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      3130032 bytes
HTML transferred:       3035971 bytes
Requests per second:    63.43 [#/sec] (mean)
Time per request:       157.646 [ms] (mean)
Time per request:       15.765 [ms] (mean, across all concurrent requests)
Transfer rate:          387.79 [Kbytes/sec] received

Sans GZ freebox=>rps :

Code:

Concurrency Level:      10
Time taken for tests:   10.025 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      10134096 bytes
HTML transferred:       10063173 bytes
Requests per second:    49.88 [#/sec] (mean)
Time per request:       200.496 [ms] (mean)
Time per request:       20.050 [ms] (mean, across all concurrent requests)
Transfer rate:          987.21 [Kbytes/sec] received

Donc pour conclure je dirai que la compression GZIP c'est bien mais sur des machines de faible puissance (RPS ou Mutu) compresser à la volée ça fait très mal.

Pour l'instant c'est encore rentable sur ce genre de machine car le gain apporté sur le temps de téléchargement depuis des visiteurs classique (adsl) et supérieur au temps de compression.

A l'opposé, dès que l'on supprime la limite de la bande passante (test serveur=>rps) on voit bien que le temps de calcul de la compression gzip nuit au performance sur des machines à faible puissance.

Donc la compression gz c'est pas la joie sur les petites machines, je pensais pas que c'était aussi gourmand.

finstreet · 9 Avril 2010

tryan a dit:
finstreet, dans tes graphes et l'utilisation de GZip, est ce que ça compresse également tout ce qui js, css, image et compagnie ou c'est encore d'autres manip. à effectuer?

Ca compresse que les php

les images j'y arrive pas, et les css non plus

Pour les autres questions aucune idée... j'ai la chance que ce soit d'office sur mon serveur

petitchevalroux · 9 Avril 2010

Les images ne se compressent pas. Pour le css et le javascript il faut regarder du cotés du cotés d'apache : section .htaccess

dorian53 · 9 Avril 2010

tryan a dit:
dorian53, tes remarques me laisse perplexe quand à la réelle utilité de "gziper" ?? Si l'internaute à un affichage plus rapide (merci medium69 ), c'est toujours ça de gagné ..non ?

Cas 1
Je zippe un fichier txt de 1Mo5. Je t'envoie le fichier txt zippé il fait 1Mo, tu le reçois plus rapidement mais tu dois désormais l'extraire du zip avant de lire le fichier qui fait 1Mo5.
Cas 2
Je t'envoie un fichier txt de 1Mo5. Tu le lis.
Conclusion
Je = serveur
Tu = navigateur
Oui il y a un gain de temps au niveau de la transition des données dans le cas 1. Mais il y a une vraie perte avant et après traitement.

finstreet a dit:
Voici ce que ca fait :

http://www.edubourse.com/blog/index.php/2010/01/22/120-google-page-spe ... sion-gzip-

Merci super retour, c'est impressionnant.
Par contre à ce niveau on ne répond pas à la question des temps de réponse.

petitchevalroux a dit:
Donc pour conclure je dirai que la compression GZIP c'est bien mais sur des machines de faible puissance (RPS ou Mutu) compresser à la volée ça fait très mal.
...
Donc la compression gz c'est pas la joie sur les petites machines, je pensais pas que c'était aussi gourmand.

De même, merci pour ce super retour honnête. Mes interrogations avaient raison d'être.

Après tryan est-ce que tu souhaitais aborder la mise en cache dans ton topic ? Car c'est aussi une solution si tu cherches à optimiser la vitesse des tes pages dynamiques.

petitchevalroux · 9 Avril 2010

dorian53 a dit:
Après tryan est-ce que tu souhaitais aborder la mise en cache dans ton topic ? Car c'est aussi une solution si tu cherches à optimiser la vitesse des tes pages dynamiques.

Et surtout ça peut supprimer le problème de la compression gzip à la volée

finstreet · 9 Avril 2010

dorian53 a dit:
Merci super retour, c'est impressionnant.
Par contre à ce niveau on ne répond pas à la question des temps de réponse.

Dans un premier temps, mauvais retour car ca a fait explosé le nombre de pages explorées par Google et donc mon serveur Mysql a eu très mal. Donc j'ai du optimiser mes requetes, pour profiter de la baisse du temps de réponses

tryan · 9 Avril 2010

petitchevalroux a dit:
dorian53 a dit:

Après tryan est-ce que tu souhaitais aborder la mise en cache dans ton topic ? Car c'est aussi une solution si tu cherches à optimiser la vitesse des tes pages dynamiques.

Cliquez pour agrandir...

Et surtout ça peut supprimer le problème de la compression gzip à la volée

La réponse est OUI.

Ce que je veux faire, c'est optimiser mon site (vitesse d'affichage) et suite à cela, je suis tombé sur le tutoriel que j'ai mis en place dans mon premier poste.

A l'heure actuelle, je suis largué de chez largué ... je ne sais plus si ce que j'ai mis en place est utile ou pas, ce que je dois ou ne dois pas faire ..etc. bref, je ne sais plus ou donner de la tête 8O !

J'ai parcourue pas mal de tutoriels, mais forcément, ils ne disent pas la même chose car les serveurs changent d'une personne à l'autre et donc la configuration.

Bref, dans mon cas précis, je suis chez 1&1 en pack perso et visiblement en mutualisé. Je n'ai donc pas accès à la "machine" et ne peut intervenir que via php, .htaccess voir php.ini d après ce que j'ai compris. Sinon, mon site c'est du fait maison et visiblement je n'ai pas de GZip dans mon phpinfo mais du zlib.

Toute aide est la bienvenue même si je suis un peut lent à la détente :mrgreen:

petitchevalroux · 9 Avril 2010

zlib c'est de la compression gzip donc c'est bon t'inquiète pas

.

En faite il est possible d'activer la compression gzip à plusieurs niveaux :
- Apache pour tes fichiers statiques (javascript et css) donc ça passe par un .htaccess sur un mutu regarde le liens que j'ai donné plus haut.
- Php activé la compression du tampon.

Le problème d'activer la compression au niveau de php c'est que à chaque fois que php sert une page il va la compresser et ensuite l'envoyer au navigateur. Ce calcul peut être néfaste au performance de ton site (comme l'a montrer mon test).

Une solution pour faire ça correctement c'est d'utiliser un cache de page qui est compressé en gzip (et de décompresser pour les rares navigateurs qui ne supporte pas) ce qui t'évite de compresser à chaque fois ta page et donc tu es gagnant dans tous les cas.

Un cache de page c'est aussi utile pour limiter le nombre de requête SQL en gros au lieux de faire :
SQL=>formatage et rendu html=>compression=>navigateur
Tu mets en cache la sortie :
SQL=>formatage et rendu html=>compression
Et tant que ton cache et valide tu n'as plus qu'a faire
cache=>navigateur
Et dans le cas des quelques navigateurs qui ne supporte pas le gz :
cache=> décompression =>navigateur

Pour le cache le plus simple c'est un cache type jpcache qui fait mumuse avec les tampons de sortie php, et il y a un sujet sur le forum la dessus avec un script "douteux" mais je ne veux pas en faire la pub :mrgreen:

tryan · 9 Avril 2010

Merci petitchevalroux pour tes explications :mrgreen: .

Bon, j'ai été lire http://www.alsacreations.com/article/lire/914-compression-pages-html-c ... flate.html et après quelques "copié/collé" est de jolies erreur 500, il en ressort que le seul truc qui semble fonctionner chez moi c'est :

Code:

<?php
ob_start("ob_gzhandler");
?>
... Le reste du code ...
<?php
ob_end_flush();
?>

Ce qui visiblement me donne le même résultat que le code de mon premier poste.

A cela, j'ai jouté le code de Mise en cache des pages PHP de fandecine trouvé ici https://www.webrankinfo.com/forum/t/script-mise-en-cache-des-pages-php.28614/ .
Donc, pour le moment sur ma page de teste, je me retrouve avec ce code :

Code:

<?php
ob_start("ob_gzhandler");

$urldemandee=$_SERVER['REQUEST_URI']; //on lit l'adresse de la page
$urldemandee=ereg_replace('/','-',$urldemandee); // on tranforme l'adresse en nom de fichier
if($urldemandee=="-") $urldemandee="-index.php"; // si l'adresse est la racine du site, on ajoute index.html
$fichierCache="cache/cache".$urldemandee; // on construit le chemin du fichier cache de la page
if (@filemtime($fichierCache)<time()-(3600*24*360)) { //si la page n'existe pas dans le cache ou si elle a expiré
   ob_start(); // on démarre la bufferisation de la page: rien de ce qui suit n'est envoyé au navigateur
?>
ICI la totalité de ma page partant du DOCTYPE jusqu'à </html>, ce qui inclue donc mes requêtes sql et tout ce qui constitue ma page.
Et je finis par :
<?php
   $contenuCache = ob_get_contents(); // on recuperre le contenu du buffer
   ob_end_flush();// on termine la bufferisation
   $fd = fopen("$fichierCache", "w"); // on ouvre le fichier cache
   if ($fd) {
      fwrite($fd,$contenuCache); // on ecrit le contenu du buffer dans le fichier cache
      fclose($fd);
     }
} else { // le fichier cache existe déjà
  include ($fichierCache); // on le copie ici
}
?>

La mise en cache semble se faire correctement etla réponse de l'entête http est la suivante:

Date: Fri, 09 Apr 2010 21:30:49 GMT
Server: Apache
Content-Encoding: gzip
Vary: Accept-Encoding
X-Powered-By: PHP/4.4.9
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

200 OK

Bon, pas bon, total à côté de la plaque ????
J'ai l'impression d'être un aveugle en plein de champ mines sur ce coup la :mrgreen: !

petitchevalroux · 9 Avril 2010

tryan a dit:
Merci petitchevalroux pour tes explications :mrgreen: .
...
J'ai l'impression d'être un aveugle en plein de champ mines sur ce coup la :mrgreen: !

Dois je comprendre que je n'ai pas été clair ? :evil:

Pour le post de alsacreation regarde juste la section : "Solutions rapides avec un .htaccess pour Apache"

Le coup du ob_gzhandler c'est ce que je préconise : activer la compression gzip. Le flush finale ne sert à rien et ton autre méthode avait l'air de fonctionner donc j'ai pas voulu insister.

Pour le code de fandecine c'est bien ce dont je parlais mais il compresse à chaque fois la sortie avec le gz_handler donc c'est bien mais tu compresses toujours à la volée ...

Pourquoi personne ne fait confiance à quickcache ou encore jpcache. Pour les avoir testé et avoir écrit des caches de page en m'en inspirant je peux te dire qu'ils sont pas mal.

PS : J'ai rien contre fandecine :mrgreen:

tryan · 10 Avril 2010

Dois je comprendre que je n'ai pas été clair ? :evil:

Tu sais, même si c'est bien expliqué et avec la meilleurs volonté, le faite de ne pas maitriser le sujet et de tester sans cesse des trucs que tu ne comprends pas forcément et qui te renvoie :"erreur 500 t'est une grosse bille" ou qui semble fonctionner, mais comme je suis une "bille" et que je doute de l'exactitude de ce que j'ai mis en place, fait que ça peut te donner cette impression :mrgreen: ... mais ce n'est pas la cas ^^.

Je veux juste est sûre de ce que je fais et en même temps comprendre la chose (ce qui n'est pas gagné je l'admet).

La compression GZip, j'ai compris, tout comme ce que fait le code de mise en cache de fandecine!

Maintenant, (plutôt demain vue l'heure ^^) je vais me pencher sur les 2 autres code que tu me proposes et consulter le lien qui va avec .

Merci de ta patience et de tes réponses

fandecine · 10 Avril 2010

petitchevalroux a dit:
Pour le code de fandecine c'est bien ce dont je parlais mais il compresse à chaque fois la sortie avec le gz_handler donc c'est bien mais tu compresses toujours à la volée ...

PS : J'ai rien contre fandecine :mrgreen:

Meuh non ! je t'en veux pas petit cheval qui trotte fièrement dans la prairie :mrgreen:

D'autant que dans mon script je n'utilise pas la compression, juste la bufferisation :wink:

Mais ce script date de quelques années et je n'utilise plus ce système.

D'une part je ne cache que les données (ce script cache du html) sous forme de tableau serialisé et d'autre part, je confie la compression au serveur HTTP (apache, lighttpd ou nginx selon le cas). En ce qui concerne PHP, j'utilise un cache d'OPCODE (eaccelerator pour ne pas le nommer). En suite, puisque l'on parle de performances, je sépare le serveur de pages dynamiques et le serveur de données statiques.

Pour répondre à ta question concernant l'utilisation de systèmes de cache existant, c'est une question d'habitude... ou de paresse :mrgreen:

tryan · 10 Avril 2010

Yo

,

Bon je viens de tester la mise en place de quickcache ... bhein c'est la me*de à mettre en place ..aucun tutoriel en français clair et précis sur la mise en place, donc à la finale ... des erreurs de partout :? ! J'ai tout désinstallé et je crois que je vais resté sur code de fandecine qui me semble plus simple ..ça m'énerve !!!

techron · 10 Avril 2010

tryan a dit:
Yo ,

Bon je viens de tester la mise en place de quickcache ... bhein c'est la me*de à mettre en place ..aucun tutoriel en français clair et précis sur la mise en place, donc à la finale ... des erreurs de partout :? ! J'ai tout désinstallé et je crois que je vais resté sur code de fandecine qui me semble plus simple ..ça m'énerve !!!

Le plus simple, Tyran, serait la solution qu'utilise Fandecine sur ses serveurs: la compression au niveau du serveur HTTP (mod_gzip/mod_deflate pour Apache) ET un cache d'opcode PHP.

Ce n'est pas supporté en mutualisé chez 1and1 mais c'est supporté par d'autres hébergeurs mutualisés, comme SIVIT, l'hébergeur de WRI. Sivit utilise APC Cache comme Opcode.

mipc · 10 Avril 2010

perso pour le code php.ini donner plus haut fonction avec la plupart des fichier j'utilise un script .HTACCESS:

Code:

AddType x-mapp-php5 .php .php3 .php4 .htm .html .js

que l'on devrait pouvoir complété par d'autre fonction pour le CSS et le reste.

tryan · 10 Avril 2010

Bon, ne criez pas svp

...

Je me suis essayé à quickcache et jpcache sans aucun succès .. donc j'abandonne définitivement ces derniers :? !

J'ai donc remit le nez dans le code de fandecine+gzip :

Code:

<?php
$urldemandee=$_SERVER['REQUEST_URI']; //on lit l'adresse de la page
$urldemandee=ereg_replace('/','-',$urldemandee); // on tranforme l'adresse en nom de fichier
if($urldemandee=="-") $urldemandee="-index.php"; // si l'adresse est la racine du site, on ajoute index.html
$fichierCache="cache/cache".$urldemandee; // on construit le chemin du fichier cache de la page
if (@filemtime($fichierCache)<time()-(3600*24*360)) { //si la page n'existe pas dans le cache ou si elle a expiré
ob_start("ob_gzhandler");//on compresse la page et on démarre la bufferisation de la page
?>

ICI LA PAGE

<?php
$contenuCache = ob_get_contents(); // on recuperre le contenu du buffer
   ob_end_flush();// on termine la bufferisation
   $fd = fopen("$fichierCache", "w"); // on ouvre le fichier cache
   if ($fd) {
      //on écrit dans le fichier pour que la page mise en cache soit compressé 
      fwrite($fd,"<?php ob_start(\"ob_gzhandler\"); ?> \n");
      fwrite($fd,$contenuCache); // on écrit le contenu du buffer dans le fichier cache
      fclose($fd);
     }
} else { // le fichier cache existe déjà
  include ($fichierCache); // on le copie ici
}
?>

ça compresse mes pages si il n'y a pas de cache.
ça créé la mise en cache.
ça compresse les pages mise en cache grâce à l'écriture en début de fichier.

Pour moi et si je ne me plante pas, je dois forcément y gagner en vitesse...

Toujours sans crier svp, vous en pensez quoi et pour qu'elle raison?

fandecine · 10 Avril 2010

Je pense que c'est un très bon script :mrgreen:

Kwaelbi · 10 Avril 2010

Personnellement j'utilise sur mes sites Wordpress le plugin WP Super Cache et il me semble qu'il marche bien.

Mais en testant un site qui n'a pas ce plugin avec le site indiqué dans le premier message ( http://www.whatsmyip.org/http_compression/ ) je vois que le site est en GZIP. Donc Wordpress est-il d'origine compressé en GZIP ?

fandecine · 10 Avril 2010

La compression peut (et c'est le cas le plus courant) être faite par le serveur HTTP :wink:

tryan · 10 Avril 2010

fandecine a dit:
La compression peut (et c'est le cas le plus courant) être faite par le serveur HTTP :wink:

Je passe en mode déprime et si tu as un lien sous la main ou c'est super bien expliqué, en français, fonctionnant sur mutualisé, ne demandant pas de triturer une quelconque machine via des codes dignes de "startrek",qui ne balance pas du erreur 500 à tout va, je suis preneur ^^.

Hooooo... chouette une corde!

detectimmobilier · 10 Avril 2010

petitchevalroux a dit:
Les images ne se compressent pas. Pour le css et le javascript il faut regarder du cotés du cotés d'apache : section .htaccess

Oui, encore faut il être sur un serveur Apache, pour ceux qui n'acceptent pas .htaccess comment peut on faire ? :wink:

fandecine · 10 Avril 2010

Non, pas besoin d'être sur un serveur Apache, tous les serveurs HTTP dignes de ce nom savent servir du contenu gzipppé (lighttpd, nginx, IIs, cherokee ettc ...), Il faut bien sur avoir accès à la configuration du serveur.

Les bidouilles avec PHP c'est un palliatif lorsque l'on a pas accès à ces fameux fichiers de conf :wink:

Pour ce qui est du htaccess, c'est juste un moyen de modifier dynamiquement le paramétrage du serveur Apache dans un dossier donné. Si le module gzip (mod_gzip pour Apache 1 ou mod_deflate pour Apache 2) n'est pas charger par le serveur (donc défini dans son fichier de configuration) il est impossible de faire quoi que ce soit.

La solution c'est de choisir une hébergement qui propose soit la compression gzip par défaut, soit permet de la configurer :mrgreen:

petitchevalroux · 11 Avril 2010

fandecine a dit:
Non, pas besoin d'être sur un serveur Apache, tous les serveurs HTTP dignes de ce nom savent servir du contenu gzipppé (lighttpd, nginx, IIs, cherokee ettc ...), Il faut bien sur avoir accès à la configuration du serveur.

Les bidouilles avec PHP c'est un palliatif lorsque l'on a pas accès à ces fameux fichiers de conf :wink:

Un serveur http fait de la compression gzip sur du fichier statique html, javascript, et css par contre à moins d'installer un reverse proxy ou autre il me semble qu'aucun serveur http ne recompresse la sortie php ... mais si tu arrive à le faire sur lighty tu m'intéresses

Désolé tryan pour moi les deux ont bien fonctionné, après ça fait un moment que je l'ai pas tester et je ne sais pas ce qu'ils sont devenu. J'aurai du tester avant de te les recommander avec insistance, j'espère que tu n'as pas perdu trop de temps à cause de moi :mrgreen:

fandecine · 11 Avril 2010

petitchevalroux a dit:
Un serveur http fait de la compression gzip sur du fichier statique html, javascript, et css par contre à moins d'installer un reverse proxy ou autre il me semble qu'aucun serveur http ne recompresse la sortie php ... mais si tu arrive à le faire sur lighty tu m'intéresses

Je confirme : Lighttpd et nginx compressent très bien les fichier générés dynamiquement. :mrgreen:

petitchevalroux · 11 Avril 2010

Tu me donnes l'eau à la bouche toi :mrgreen:

We currently limit to compression support to static files.

source

Pour le truc russe j'en sais rien, mais j'aime pas les russes :mrgreen:

fandecine · 11 Avril 2010

petitchevalroux a dit:
Tu me donnes l'eau à la bouche toi :mrgreen:

We currently limit to compression support to static files.

Cliquez pour agrandir...

source

Pour le truc russe j'en sais rien, mais j'aime pas les russes :mrgreen:

Oui mais plus loin : :wink:

PHP¶

To compress dynamic content with PHP please enable ::

zlib.output_compression = 1
zlib.output_handler = On

in the php.ini as PHP provides compression support by itself.

mod_compress of lighttpd 1.5 r1992 may not set correct Content-Encoding with php-fcgi.
A solution to that problem would be:

1.disable mod_compress when request a php file::

$HTTP["url"] !~ "\.php$" {
compress.filetype = ("text/plain", "text/html", "text/javascript", "text/css", "text/xml")
}

2.enable mod_setenv of your lighttpd::

server.modules += ( "mod_setenv" )

3.manually set Content-Encoding::

$HTTP["url"] =~ "\.php$" {
setenv.add-response-header = ( "Content-Encoding" => "gzip")
}

petitchevalroux · 11 Avril 2010

Oui donc c'est php qui compresse et pas lighty, le problème c'est que si c'est php qui compresse il recompresse à chaque fois, et comme le montre mon bench de debut de thread ça fait mal sur les serveurs de pauvre genre RPS :mrgreen:

fandecine · 11 Avril 2010

J'utilise lighttpd 1.5 avec "mod_deflate" ( different du mod_compress de lighttpd 1.4) et je te garanti que c'est lighty qui compresse et pas php :

Code:

php.ini

zlib.output_compression = Off

Code:

lighttpd.conf

	deflate.enabled = "enable"
	deflate.compression-level = 9
	deflate.mem-level = 9
	deflate.window-size = 15
	deflate.allowed_encodings = ( "bzip2", "gzip", "deflate" )
	deflate.min-compress-size = 200
	deflate.work-block-size = 512
	deflate.mimetypes = ("text/html", "text/plain", "text/css", "text/javascript", "text/xml")

Tu peux installer mod_deflate avec lighttpd 1.4 en applicant un patch :wink:

cedric_g · 11 Avril 2010

Bonjour

Je viens de mettre en place la compression via le htaccess sur quelques uns de mes sites (dont mon site photo), ça dépote, rien à dire (j'utilisais déjà une mise en cache - en l'occurrence CacheLite - pour les appels BDD au sein du site...)

J'ai même un site qui vient de passer en Grade A sur YSlow :mrgreen: (c'est l'anecdote) ; sur un autre je gagne 40% (!) de poids de page en moyenne.

Par contre quid de la mise en place sur des CMS genre Wordpress ?... Il semble que WPSuperCache permet d'activer la compression à la volée...

Au niveau du délai de mise en cache via htaccess, il gère comment les mises à jour de pages ? Si je cache mes pages php par exemple avec un délai d'un jour ? J'ose pas faire l'essai

petitchevalroux · 11 Avril 2010

fandecine a dit:
J'utilise lighttpd 1.5 avec "mod_deflate" ( different du mod_compress de lighttpd 1.4) et je te garanti que c'est lighty qui compresse et pas php

Autant pour moi, je suis bloqué en 1.4 sur la debian et je veux pas me lancer dans la compilation et/ou patch. En tout cas je suis ravi de découvrir cette fonctionnalité. Merci beaucoup pour l'info, ça fait plaisir de discuter avec qqn qui connait autre chose que apache :mrgreen:

petitchevalroux · 11 Avril 2010

cedric_g a dit:
Au niveau du délai de mise en cache via htaccess, il gère comment les mises à jour de pages ? Si je cache mes pages php par exemple avec un délai d'un jour ? J'ose pas faire l'essai

Tu parles de quel cache là ? mod_cache, mod_proxy ... ou juste du cache cotés client (LastModified, Expire .. )?

cedric_g · 11 Avril 2010

Ce type de code :

Code:

# Mise en cache pour 2 semaines concernant les images
<FilesMatch "\.(html|php)$">
Header set Cache-Control "max-age=3600, public"
</FilesMatch>

Il me cache les pages (leur contenu) pour 1 heure. Si je claque ça sur un blog par exemple, et qu'un commentaire est posté, ça se passe comment : il est affiché ou il le sera au bout de l'heure écoulée ?

Je ne saisis pas vraiment le fonctionnement côté serveur en fait...

fandecine · 11 Avril 2010

petitchevalroux a dit:
fandecine a dit:

J'utilise lighttpd 1.5 avec "mod_deflate" ( different du mod_compress de lighttpd 1.4) et je te garanti que c'est lighty qui compresse et pas php

Cliquez pour agrandir...

Autant pour moi, je suis bloqué en 1.4 sur la debian et je veux pas me lancer dans la compilation et/ou patch. En tout cas je suis ravi de découvrir cette fonctionnalité. Merci beaucoup pour l'info, ça fait plaisir de discuter avec qqn qui connait autre chose que apache :mrgreen:

J'utilise lighttpd 1.5 depuis exactement le 7 sept 2007 et cette version, non encore dite stable et visiblement plus développée me donne entière satisfaction pour un serveur d'images et de vidéos (php en fcgi est juste là pour la partie admin).

La compilation est hyper simple et si tu veux j'ai un tuto complet pour Debian (j'ai du l'utiliser pour une cinquantaine de serveurs depuis 2 ans) :wink:

petitchevalroux · 11 Avril 2010

cedric_g a dit:

Ce code met ta page en cache cotés client c'est à dire dans le navigateur du visiteur, cotés serveur il n'y a aucun cache avec ce genre de code.

Si le visiteur A visite ta page et qu'il poste un commentaire, lorsqu'il réaffiche ta page son navigateur doit normalement lui réafficher la page depuis son cache et donc la version sans le commentaire.

Si un visiteur B arrive après que le visiteur A ai posté son commentaire et qu'il n'a pas la page en cache (ou que le cache est périmé > 1h) il verra le commentaire du visiteur A alors qu'au même moment le visiteur A lui ne le voit pas :mrgreen:.

Dans ces explications je suppose que l'url de page ne change pas, et que tu n'affiches les commentaires en ajax

.

cedric_g · 11 Avril 2010

Yep

Pas de commentaires en AJAX (pas encore en tout cas !)

Enfin bon, je vais prochainement passer sous Wordpress mon vieux blog, et là WP SuperCache intègre toutes ces fonctionnalités

donc no soucie.

petitchevalroux · 11 Avril 2010

fandecine a dit:
La compilation est hyper simple et si tu veux j'ai un tuto complet pour Debian (j'ai du l'utiliser pour une cinquantaine de serveurs depuis 2 ans) :wink:

Tu peux toujours faire passer le lien que je bookmark, mais ça m'étonnerai que je m'en serve :mrgreen:

webinyou · 13 Avril 2010

Il y a quelques mois, je travaillais sur la mise en cache de mes pages, puis la compression à la volée de ces dernières avant de l'envoyer au navigateur en activant la compression dans les fichiers de configuration.
J'ai lu dans un article, que je n'arrive plus à mettre la main dessus, qui précisait que la compression prenait 5% des ressources du CPU. Donc, à la fin, je me demandais si réellement cela valait la peine de mettre en place ce genre de configuration, car j'estimais que le "temps de compression du serveur + transfert des données compressées + temps de décompression du navigateur" était pas forcément avantageux en terme de vitesse d'affichage que le transfert de données brutes à lui seul. Puis, une idée m'est venue : et si je mettais en cache les données (pages) au format compressé au lieu de données brutes ?

Cela signifie que :
- les pages ne sont plus compressées à la volée, mais dès la création de la page ou au premier appel de la page : gain de ressource lors de la requête sur la page
- le téléchargement est plus rapide : la taille de la page est réduite, puisqu'elle est compressée
- la décompression s'effectue par le navigateur, donc ne nécessite aucune action de la part du serveur

Cela m'oblige à prendre en compte les navigateurs qui ne peuvent pas gérer la compression/décompression et/ou format de compression. De ce fait, je gère 3 formes de caches :
1. cache au format gzip
2. cache au format deflate
3. cache normal au format texte ou données brutes

Avant d'envoyer les données, je vérifie si le navigateur accepte la compression deflate. Si c'est OK alors je lui envoie les données au format deflate, sinon je vérifie s'il accepte la compression gzip. Si oui, alors j'envoie les données au format gzip, sinon j'envoie les données brutes traditionnelles.

Cette technique à l'avantage d'accélérer le transfert, car les fichiers sont réduits au maximum en taille par la compression, mais son inconvénient, c'est que cela nécessite de l'espace disque pour stocker les fichiers gzip, deflate et brute par page.

petitchevalroux · 13 Avril 2010

Très bon choix webinyou, perso je n'ai pas 3 versions de cache mais juste le gz, si un navigateur ne le supporte pas je décompresse et parreil si il supporte seulement le deflate. Cela me permet d'avoir un seul cache mais ta solution est bien plus performante.

C'est souvent le dilemme avec le cache : Espace disque (ou mémoire) vs rapidité et il faut faire des choix :mrgreen:

webinyou · 13 Avril 2010

Actuellement, je n'ai pas mal d'espace disque, c'est la raison pour laquelle j'ai 3 formats de caches différents. Je préfère dépenser de l'espace disque que de la ressource en CPU. Cependant, si un jour j'arrive à avoir un site comme WRI, je serais certainement en manque d'espace disque. Par conséquent, je réduirai le nombre de format de cache de 3 à 2, puis à 1 (données brutes). Au pire, j'ajoute de l'espace disque si mes finances personnelles le permettent. C'est aussi une histoire de sous :lol:

MaryPopy · 13 Avril 2010

Je profite du sujet pour poser ma question :

Mon hébergeur propose ce code pour compresser en Gzip mais ne fournit aucun renseignement sur ou lemettre...

Est-ce dans l'index.php ou dans les dossiers includes ou sont mes php qui correspondent aux pages html ?

J'ai un annuaire freeglobes.

Code:

function compress_output($output)
 {
// We can perform additional manipulation on $output here, such
// as stripping whitespace, etc.
return gzencode($output);
 }

// Check if the browser supports gzip encoding, HTTP_ACCEPT_ENCODING
if (strstr($HTTP_SERVER_VARS['HTTP_ACCEPT_ENCODING'], 'gzip')) {
// Start output buffering, and register compress_output() (see
// below)
ob_start("compress_output");

// Tell the browser the content is compressed with gzip
header("Content-Encoding: gzip");
}

compress_output('Test de compression');

Si non, si l'effet est le même il donnent ce code également :

Seul description: Il suffit de rajouter ceci dans votre web/.htaccess

Code:

AddOutputFilter INCLUDES;DEFLATE js
AddOutputFilter INCLUDES;DEFLATE html
AddOutputFilter INCLUDES;DEFLATE xml
AddOutputFilter INCLUDES;DEFLATE txt

Voici un exemple de l'effet de l'ajout dans web/.htaccess de ceci
"AddOutputFilterByType INCLUDES;DEFLATE application/x-javascript"

AVANT

$ lynx -mime_header http://votresite/javascript/script.js | head -n10
HTTP/1.1 200 OK
Date: Mon, 26 Nov 2007 15:14:03 GMT
Server: Apache
Last-Modified: Tue, 02 Oct 2007 02:12:22 GMT
ETag: "863a1d0-1165d-1557cd80"
Accept-Ranges: bytes
Content-Length: 71261
Connection: close
Content-Type: application/x-javascript

APRES

$ lynx -mime_header http://votresite/javascript/script.js | head -n10
HTTP/1.1 200 OK
Date: Mon, 26 Nov 2007 15:16:17 GMT
Server: Apache
Last-Modified: Tue, 02 Oct 2007 02:12:22 GMT
ETag: "863a1d0-1165d-1557cd80"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 16313
Connection: close

Seulement voilà... Je n'ai vu aucune différence.

Je ne comprend pas ce qu'est le "avant" "après" ! En tous cas je n'ai trouvé aucun moyen fiable de tester la rapidité.
Dois-je créer un fichiers js ? Ou le code dans le htaccess suffit ?

Je ne sait pas le quel de ses deux solutions me convient car j'ai juste besoin de compresser toutes les pages qui seront vue pas les intarnautes.

Merci à la personne qui saura me répondre

mipc · 13 Avril 2010

MaryPopy a dit:
AVANT

$ lynx -mime_header http://votresite/javascript/script.js | head -n10
HTTP/1.1 200 OK
Date: Mon, 26 Nov 2007 15:14:03 GMT
Server: Apache
Last-Modified: Tue, 02 Oct 2007 02:12:22 GMT
ETag: "863a1d0-1165d-1557cd80"
Accept-Ranges: bytes
Content-Length: 71261
Connection: close
Content-Type: application/x-javascript

APRES

$ lynx -mime_header http://votresite/javascript/script.js | head -n10
HTTP/1.1 200 OK
Date: Mon, 26 Nov 2007 15:16:17 GMT
Server: Apache
Last-Modified: Tue, 02 Oct 2007 02:12:22 GMT
ETag: "863a1d0-1165d-1557cd80"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 16313
Connection: close

Seulement voilà... Je n'ai vu aucune différence.

Je ne comprend pas ce qu'est le "avant" "après" ! En tous cas je n'ai trouvé aucun moyen fiable de tester la rapidité.
Dois-je créer un fichiers js ? Ou le code dans le htaccess suffit ?

Je ne sait pas le quel de ses deux solutions me convient car j'ai juste besoin de compresser toutes les pages qui seront vue pas les intarnautes.

Merci à la personne qui saura me répondre

la différence c'est: Content-Encoding: gzip

ça veut dire que les fichier HTML tous du moins sont compresser en GZIP.

pour tester la vitesse de chargement avant après utilise http://webwait.com/

mais tu peux aussi tester VIA PAGESPEED via FIREBUG ou encore WEB DEVELOPER.

perso avec GZIP j'ai vue un gain notable, mais ça peut être l'inverse sur les petites config ou les connexions très lentes!!!

MaryPopy · 13 Avril 2010

Ah bin j'avais la solution... J'ai 85% de compression avec

Code:

function compress_output($output)
{
// We can perform additional manipulation on $output here, such
// as stripping whitespace, etc.
return gzencode($output);
 }

// Check if the browser supports gzip encoding, HTTP_ACCEPT_ENCODING
if (strstr($HTTP_SERVER_VARS['HTTP_ACCEPT_ENCODING'], 'gzip')) {
// Start output buffering, and register compress_output() (see
// below)
ob_start("compress_output");

 // Tell the browser the content is compressed with gzip
 header("Content-Encoding: gzip");
 }
 
compress_output('Test de compression');

Dans chaque include

tryan · 13 Avril 2010

MaryPopy, tu utilises ce code sur quelle hébergeur ?

Pour en revenir à GZip, mieux vaut l'utiliser ou pas?
Je me tâte à mettre la compression en place uniquement sur les fichiers en cache...fausse bonne idée?

petitchevalroux · 13 Avril 2010

tryan a dit:
Pour en revenir à GZip, mieux vaut l'utiliser ou pas?
Je me tâte à mettre la compression en place uniquement sur les fichiers en cache...fausse bonne idée?

Moi je te dirai de le mettre en place si ça te prend pas 10 ans et de regarder ce que ça donne sur les graphs de GWT maintenant que ça compte dans les SERPS :mrgreen:.

tryan · 13 Avril 2010

oki, uniquement sur la version en cache ou pas en cache ou les 2 selon toi ?

Sinon, il y a un truc que je n'arrive pas à intégré niveau neuronal

, ce code :"ob_start("ob_gzhandler");", compresse quoi exactement..php,html,css,javascript?

Fait il exactement la même chose que l'intégration via htaccess+php.ini ?

Promit, après j'arrête le harcèlement :mrgreen:

MaryPopy · 13 Avril 2010

Lol, j'métais mis à mettre dans tout les includes car sa fonctionnait mais j'ai remarqué une fos fini qu'il y avait plus rapide... En tête du index.php sa l'a activé sur toutes les pages. :lol:

Je suis chez infomaniak

Salut