Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Salut à tous zaidfaiyens!
Je viens de lire un petit article sur la compression à la volée des pages qui permet de gagner un peu en taille (15 à 30%...) et je me suis aperçu que jQuery (une bonne librairie javascript) propose de compresser son code pour avoir une taille encore plus réduite. Alors j'me dis "Moi aussi j'vais jaizipper (gzippé) mes pages!".
Alors je cherche un peu, je tombe sur ça : http://www.en1heure.com/compresser_ses_ … eflate.php . Moi "content", car simple et gratos (et surtout sans problème de compatibilité majeur). Le truc tout bête est d'utiliser un tampon de sortie qui compresse directe quand on entasse... alors on rajoute au début de la capture de la sortie:
<?php ob_start("ob_gzhandler");
Mais là j'me dis que le Zend Framework utilise peut être (sûrment) un système de tampon pour gérer les vues, et du coup j'me dis que mon "truc" pour compresser marchera. Et je sais pas comment savoir...
Quelqu'un a-t-il le savoir sur ce coup?
Hors ligne
Alors, non, ZF n'utilise pas ceci, car cela necessite l'extension gzip, ce qui ne va pas dans le sens de ZF.
Tu peux en effet compresser ton flux via cette commande, le mieux est de la redéfinir dans la vue, dont voici une partie de la structure :
public function render($name) { // find the script file name using the parent private method $this->_file = $this->_script($name); unset($name); // remove $name from local scope ob_start(); $this->_run($this->_file); return $this->_filter(ob_get_clean()); // filter output }
Transforme l'ob_start() ici.
Attention, si la directive zlib.output_compression est activée, ca ne fonctionnera pas car le flux est déja compréssé ( certains hebergeurs économisent de la bande passante en activant par défaut la compression de flux dans PHP ).
Il est aussi possible d'activer cette extension au niveau du serveur directement.
Hors ligne
Merci de ta réponse rapide.
Je regarde ça et j'vous tiens au courant.
EDIT:
mon phpinfo() me resort ça
ZLib Support enabled Stream Wrapper support compress.zlib:// Stream Filter support zlib.inflate, zlib.deflate Compiled Version 1.2.1 Linked Version 1.2.1 Directive Local Value Master Value zlib.output_compression Off Off zlib.output_compression_level -1 -1 zlib.output_handler no value no value
Moi je vois enable desuite je suis content, je rempli mon htaccess avec ça
php_flag zlib.output_compression On php_value zlib.output_compression_level 5
et en faite ça marche pas...
J'vais voir avec la vue...(et avec mon sav hebergeur mais j'y crois pas trop)
Dernière modification par Mr.MoOx (18-09-2007 02:00:17)
Hors ligne
Je continu à poster tout seul... J'ai donc testé ceci dans mon code php
ini_set('zlib.output_compression', 'On'); ini_set('zlib.output_compression_level', '5');
Je n'ai pas d'erreurs mais je me demande si ça marche. Comment vérifier que ça compresse bien ?!
EDIT: on peux le voir par les entêtes HTTP (par exemple avec l'extension web developper de firefox) où à l'aide d'un petit site (http://www.gidnetwork.com/tools/gzip-test.php ou encore http://leknor.com/code/gziped.php )
Dernière modification par Mr.MoOx (18-09-2007 10:23:14)
Hors ligne
Et alors, ça marche? Si c'est aussi simple que ça moi aussi je vais utiliser Zlib ^^
Hors ligne
Non ça marche pas sur mon hébergeur. J'ai essayé aussi en changeant le render() dans ma vue mais ça marche pas non plus...
Logiquement c'est simple... :-(
Reste plus qu'à voir avec mon hébergeur...
EDIT: sur un autre hébergeur (sivit) j'ai réussi avec la méthode ob_start("ob_gzhandler"); ... mais sans le zend framework...
Dernière modification par Mr.MoOx (18-09-2007 11:25:11)
Hors ligne
D'après ce que j'ai compris :
- il ne faut utiliser la compression Gzip que si le serveur http n'en fait pas.
Y a t-il un moyen de le savoir par code ? Comment être sur qu'il ne le fera jamais ?
- bufferiser la sortie (ob_) optimise le flux réponse de manière propre
C'est toujours un soucis quand plusieurs intervenants on la possibilité de faire la même chose (le serveur,php ou le code)
If faut pouvoir tester dans son code, comme pour les magic_quotes_gpc si ce n'est pas fait à un niveau supérieur.
En règle générale,
- Je pense que ce n'est pas à l'application de gérer les perfs réseau. C'est bien le boulot du serveur ça.
On devrait même pouvoir agir sur la bufferisation au niveau de php et non par code (ob_).
- Ne pas faire confiance aux autres couches pour la sécurité (magic_quotes_gpc)
Qu'en pensez vous ?
Hors ligne
Ben je dis effectivement que c'est au niveau du serveur de le gérer.
Perso c'est comme ça que je procède aujourd'hui.
Moi j'active ça tout le temps quand le serveur le permet. Après c'est le client qui peut ou pas décodé en gzip. Donc soit directe configurer sur le httpd.ini ou à la limite avec un coup de .htaccess.
Mais j'évite de gérer ça au niveau du php maintenant.
Hors ligne
Il est en effet préférable de laisser le serveur gérer la négociation avec le client.
Si le client envoie des en-têtes comme quoi il est capable de recevoir du gzip (deflate), alors le serveur (je parlerai d'Apache) , si il est configuré pour, peut servir un contenu compréssé.
La RFC 2616 vous en apprendra plus ( bon courage )
De nos jours, c'est très souvent le cas, car cela permet une économie très importante de bande passante (qui est très chère), pour une charge processeur très raisonnable (2 à 5% supplémentaires en moyenne).
Il n'est pas interdit d'interroger son serveur manuellement (avec un client textuel, putty, curl ....) afin de voir les en-têtes de réponse et de faire par la même occaz des tests de sécurité ^^
Des extensions FF existent aussi (LiveHTTPHeaders)
Hors ligne
Dans la conf apache il faut penser à exclure ce qui ne doit pas être compressé. La plupart des fichiers binaires sont déjà compressés (jpg, gif, mp3, flv, png,...).
A+, Philippe
Hors ligne
La compression a du bon pour la bande passante mais elle a aussi des inconvénients.
Je peux en donner au moins un, IE ne sais pas gérer les etags lorsque la page est compressée.
Si, dans les entêtes, vous ne géré que les etags et pas de expires, vous n'aurez plus aucun 304 avec IE.
Du coup, le gain obtenu peut être nettement amoindri voir négatif faute de 304.
Certain browser (IE5) ont aussi des pb de rendu lors de la compression des css.
Hors ligne