Bonjour, j'utilise en PHP, le petit truc suivant :
 
 ob_start();
 ini_set(zlib.output_compression,"1" );
Censé compresser les pages et censé être plus efficace que ob_start('ob_gzhandler');
De plus, j'ai un soucis avec ob_gz sous IE que je ne pige pas.
 
En fait, j'aurais voulu savoir comment tester "l'efficacité" de cette fonction et m'assurer qu'elle est bien active ou non.  
Si vous savez comment faire, ça serait sympa de partager l'info.
 
Merci d'avance.

Bon bah résolu tout seul.
 
si ça intéresse quelqu'un, grace au site : http://www.whatsmyip.org/mod_gzip_test/
 

The-Shadow > tu aurais un tutoriel pour compresser les pages ?

Bah, c'est tout simple, tu vas dans ton php.ini et tu actives la compression zlib.
Tu peux modifier en cours de page avec ini_set :
http://www.nexen.net/docs/php/anno [...] ni-set.php
 
Il y a une autre méthode, c'est de préciser à la mise en buffer de ta page, avec obstart('gzhandler') au début de chaque script, mais bizarrement, chez moi, ça merde royal sous IE.

en gros je met ob_start("ob_gzhandler" ); dans chaque debut de page ?

Tu peux le faire comme ça, mais chez moi, ça pose des problèmes sous IE et dans la doc PHP, ils disent qu'il est préférable de passer par zlib.compression-output.
Donc, soit tu as accès à ton php.ini et tu mets la compression auto à On, soit tu forces le changement de paramètres avec ini-set, par contre, il faut que le serveur où est installé ton interpréteur PHP, PHP ait été compilé avec l'option adéquate, mais c'est souvent le cas.

j'ai mis auto à On dans le php.ini
 
j'ai rien a faire d'autre si j'ai mis ca ?

Nop, rien d'autre, utilise le lien que je t'ai mis plus haut pour tester.
Ha si, ça peut sembler évident, mais je le dis au cas où, il faut quand même redémarrer Apache.

Des gains, des contraintes?

Les gains sont clairs, réduire le poid des pages d'un quart.
Par exemple, l'index du forum HFR met une seconde à charger sur un 56k, sans la compression, il mettrait 6 fois plus.
Les contraintes, je n'en vois pas encore. ob_gzhandler provoquait des problèmes chez moi, mais la compression par la reconfiguration du php.ini, tout fonctionne niquel et mes sites vont nettement plus vite.

Sur les navigateurs comprennants la compression mais sinon?
 
edit: 1/4, 6 fois plus faut choisir

Une idée parce que si tu gères ton tampon comme un cochon son temps d'affichage dépend de la connexion
 
Sur une page en locale générée en 0.1s tu peux arriver à 10s avec les temps de connexion si t'utilises pas les tampons
 
Mais c'est différent d'utiliser une compression encore

En théorie et selon la doc PHP, si le navigateur ne supporte pas la compression, PHP reçoit l'info et agit en conséquence.
 

ça varie en fonction des pages, une compression n'est jamais fixe.

 
1- oui donc justement?
2- appelle 'moi con' Oui 'moi con' pour leflos5
 
Mais je réitère, sur un truc à la con donné sans tampon ça rame surtout si beaucoup de réflexion cpu entre temps (plusieurs accès BD suffisent) si tampon tu divises par 10 voir plus, donc je redemande, le gain en compression se fait biensur que si compression ou parce que tu utilises les tampons au lieu de faire du echo partout à la chié par dessus la jambe à tour de bras

Les 2 je penses, vu qu'il compresse la page, je pense que la bufferisation doit avoir lieu.
Mais je ne sais pas exactement comment ça fonctionne, ce que je sais, c'est que ça fonctionne et sur des pages lourdes comme sur un forum ou un portail, le gain est bien visible.

Ca répond pas à la question
 
Si on bufferise pas ça rame, normal, mais si buffer la différence?

sans buffer, PHP envoie les echo par bloc au serveur web. Qui lui-meme selon sa configuration va l'envoyer au navigateur afin d'etaler au mieux la BP.  
Les echanges reguliers ralentissent l'execution des scripts. Le buffer est pratique car il evite ses echanges, permet la compression qui peut reduire au 1/10e les données HTML (pas les données d'echanges entre Apache et le navigateur).

Je demandais la différence de perf entre un zlib d'un gandzler par défaut

temps de compression? Ou taille des données compressée?  
 
L'un comme l'autre je dirais que c'est kifkif sur la taille. Pour le temps de compression, a moins d'avoir une charge serveur tres importante, je doute  que l'on sente la difference.

Etant donné qu'il ne compresse que les fichiers html qui sont du texte et souvent de petites tailles, la compression est ridicule.

la taille? Ou le temps?
 
Si c'est la taille, la compression sera tres importante. Sur mon site, actuellement une page fait dans les 50ko (données générées par PHP), pour finir à 5ko une fois compressée. C'est tout de meme tres interessant un gain de 90%.

Oui, bien sûr, je parlais de la durée de compression qui est ridicule.
la compression, comme on peut s'y attendre sur un fichier texte, est-elle, excellente.

j'ai fait des bench apache pour comparer. Sur mon petit serveur (800MhZ), ca consommait 5% de ressource en plus. Ca avait donc un impact leger sur le nb de pages générées. Par contre, en gain de BP c'est enorme.

Y'a un autre énnnoorrrmmmeee avantage que je viens de découvrir.
 
En faisant une exportation des bases de données via PHPmyAdmin, la compression fonctionne, du coup, moi pour qui d'habitude, faire une sauvegarde de l'intégralité de mes tables prends plusieurs heures (en 512), là il me récupère mon dump en moyen à 630ko/s via Firefox.
Bon, apache mouline entre 20 et 40% de puissance CPU sur mon dédié, mais pour 300Mo, il y en a pour 20 minutes à tout casser.

Tout est là, la BP etant reguliere le goulot d'etranglement.