Compression et décompression de données.

Le
WebShaker
Salut.

J'ai des requêtes AJAX qui retournent quelques kilo de données.

Je me demandais si quelqu'un avait déja développé une compression de
donnée JSON (en PHP par exemple) et la décompréssion Javascript associée.

Et surtout si cela avait un impact

Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms, ce qui n'est pas énorme mais bon s'il y avait
moyen de diviser par deux, pourquoi ne pas le faire.

Etienne
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #22658341
À (at) Fri, 08 Oct 2010 23:49:08 +0200,
WebShaker
J'ai des requêtes AJAX qui retournent quelques kilo de données.

Je me demandais si quelqu'un avait déja développé une compression de
donnée JSON (en PHP par exemple) et la décompréssion Javascript
associée.

Et surtout si cela avait un impact...

Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms, ce qui n'est pas énorme mais bon s'il y avait
moyen de diviser par deux, pourquoi ne pas le faire.



Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).

--
Paul Gaborit -
SAM
Le #22658391
Le 08/10/10 23:49, WebShaker a écrit :
Salut.

J'ai des requêtes AJAX qui retournent quelques kilo de données.



Ha! Oui ! quand même ! ;-)

Je me demandais si quelqu'un avait déja développé une compression de
donnée JSON (en PHP par exemple) et la décompréssion Javascript associée.



(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct,
zippé, il fait 1133 oct ... en gz ... pas essayé)

Et surtout si cela avait un impact...



Le seul impact est de bien penser ses requêtes et l'optimisation des
données à la Json.
(à mon idée, et vu de ma chaise)

Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms,



Je me demande bien sur quoi il se base ?
Que sait-il de la qualité de "ma" connexion ?

ce qui n'est pas énorme mais bon s'il y avait
moyen de diviser par deux, pourquoi ne pas le faire.



Si je comprends bien c'est une appli qui n'est qu'à ton profit,
puisque tu te bases sur les vitesses de "ton" équipement.

Etienne



J'ai comme idée que les trucs Json peuvent être parfois assez
lourdingues, peut-être faut-il voir s'il est possible de les alléger?
Par exemple :

--
Stéphane Moriaux avec/with iMac-intel
SAM
Le #22658431
Le 09/10/10 00:36, Paul Gaborit a écrit :

À (at) Fri, 08 Oct 2010 23:49:08 +0200,
WebShaker
J'ai des requêtes AJAX qui retournent quelques kilo de données.

Je me demandais si quelqu'un avait déja développé une compression de
donnée JSON (en PHP par exemple) et la décompréssion Javascript
associée.

Et surtout si cela avait un impact...

Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms, ce qui n'est pas énorme mais bon s'il y avait
moyen de diviser par deux, pourquoi ne pas le faire.



Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).



Je ne sais si les navigateurs dégzippent les codes JavaScript ...

Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est
en fonctionnement, et il attend du texte (de code JS ?) en clair, j'imagine.

De toutes façons, pour "quelques" ko ... on ne va rien gagner.
Ça ne peut fonctionner bien que pour des listes ou tables *à rallonge*
(la compression agissant surtout sur les redondances)

en dessous de 50ko gzip, le temps de calcul du décompactage sera
supérieur au gain de temps du transfert de, disons 65 ko brut
(sauf, peut-être, en RTC ?)


--
Stéphane Moriaux avec/with iMac-intel
Paul Gaborit
Le #22658481
À (at) Sat, 09 Oct 2010 00:56:23 +0200,
SAM
Le 08/10/10 23:49, WebShaker a écrit :

Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms,



Je me demande bien sur quoi il se base ?
Que sait-il de la qualité de "ma" connexion ?



Il n'en sait rien ! ;-)

Firefox (via Firebug, j'imagine) ne fait que mesurer le temps entre le
début de l'envoi de la requête et la fin de la réception de la
réponse. La vrai question est : où ce temps est-il consommé ? Il y a le
transfert de la requête, le traitement et le transfert de la réponse. Un
temps de 250 à 300 ms n'est certainement pas pris par le transfert de
quelques kilo-octets de données (surtout si c'est un test local). À mon
avis, c'est plutôt le temps de traitement qui est en cause. Si c'est un
CGI qui répond, l'utilisation de FastCGI est un moyen facile d'améliorer
les choses.

J'ai comme idée que les trucs Json peuvent être parfois assez
lourdingues, peut-être faut-il voir s'il est possible de les alléger?
Par exemple :



L'article cité ci-dessus est un exemple typique de mauvaise réponse à un
vrai problème. Une simple compression des données (traitée directement
par le serveur et par la navigateur) réalise une bien meilleure
optimisation de la taille des données transférées sans avoir à écrire la
moindre ligne de code (puisque ces fonctions de compression sont déjà
écrites, débuguées et optimisées depuis longtemps) et avec l'avantage de
savoir traiter n'importe quelle structure de données...

--
Paul Gaborit -
Paul Gaborit
Le #22658491
À (at) Sat, 09 Oct 2010 01:58:19 +0200,
SAM
Je ne sais si les navigateurs dégzippent les codes JavaScript ...

Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est
en fonctionnement, et il attend du texte (de code JS ?) en clair,
j'imagine.



Mais du text/json c'est exactement la même chose que du text/html, du
text/css ou du text/xml. A priori, on attend du texte clair. Mais rien
n'empêche de le compresser puisqu'il sera décompresser avant d'être
fourni au code javascript. Le seul cas qui pourrait poser problème
serait MSIE 6 qui est, semble-t-il, assez chatouilleux sur ce qu'on a le
droit de compresser ou non... À tester !

--
Paul Gaborit -
Guy Ratajczak
Le #22658731
Le 09/10/2010 00:56, SAM a écrit :
Le 08/10/10 23:49, WebShaker a écrit :
Je me demandais si quelqu'un avait déja développé une compression de
donnée JSON (en PHP par exemple) et la décompréssion Javascript associée.



(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct,
zippé, il fait 1133 oct ... en gz ... pas essayé)



Le post d'origine avec en-tête fait 1299 octets. Voici le résultat de
son transfert en HTTP gzipped :

Content-Encoding:gzip
Content-Length:833
Content-Type:text/html

De 1299 à 833 ça fait un bon ratio.
Et comme le disait Paul, c'est le serveur qui fait le boulot. Pas besoin
d'implémenter soit même une compression avec tous les problèmes que cela
peut poser.

Et surtout si cela avait un impact...



Le seul impact est de bien penser ses requêtes et l'optimisation des
données à la Json.
(à mon idée, et vu de ma chaise)



L'idée est là :
- d'abord bien penser ses requêtes et les données à renvoyer ;
- ensuite optimiser, notamment avec la compression.

J'ai comme idée que les trucs Json peuvent être parfois assez
lourdingues, peut-être faut-il voir s'il est possible de les alléger?



C'est la première partie de l'optimisation : être sûr de n'envoyer que
des données nécessaires.

Bonne journée,
--
Guy
WebShaker
Le #22658811
Le 09/10/2010 00:36, Paul Gaborit a écrit :
Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).



En effet, je n'y avait pas pensé. je vais tester.
Etienne
SAM
Le #22658921
Le 09/10/10 10:10, WebShaker a écrit :
Le 09/10/2010 00:36, Paul Gaborit a écrit :
Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).



En effet, je n'y avait pas pensé. je vais tester.
Etienne



Je suis très intéressé car ...
je n'imaginais pas qu'un navigateur pouvait décompresser à la volée
un "responseText"


--
Stéphane Moriaux avec/with iMac-intel
Etienne
Le #22666321
Le 09/10/2010 10:55, SAM a écrit :
Je suis très intéressé car ...
je n'imaginais pas qu'un navigateur pouvait décompresser à la volée
un "responseText"



Ok.

bon alors c'est extrêmement simple a mettre en place.

Il suffit de mettre dans les .htaccess la ligne
AddOutputFilterByType DEFLATE text/html text/xml

Cela permet par exemple de ne compresser qu'un seul dossier (celui des
requêtes ajax) encore que j'imagine que tout doit être bon à compresser.

J'en arrive tout de suite au résultat.
C'est extrêmement intéressant.

Difficile de quantifier exactement.

La partie script prends un peut plus de temps.
Je dirai que dans mon c'est passé de 100 a 200 ms. (il ne faut pas en
conclure que ca double mais plutot que la compression prend environ 100 ms)

Par contre le temps de transfert est quand à lui passé de 350ms à 50ms.
Soit un temps non négligeable. les données originales faisaient environ
60ko.

Dans tous les cas de figures, ca va plus vite, et sur des requêtes ajax
rapide qui renvoient pas mal de données et c'est directement perceptible.

Donc.
ben a utiliser sans modération à partir du moment ou votre serveur n'est
pas sur les genoux.

Etienne
Etienne
Le #22666561
Le 11/10/2010 13:52, Etienne a écrit :
Difficile de quantifier exactement.



Bon j'étais un peu frustré du ne pas pouvoir bencher plus précisement le
gain obtenu.
J'ai donc écrit un petit script qui me permet de mieux quantifier tout
ca et qui consiste a éxécuter 50 fois la requête ajax et réaliser une
moyenne.

Donc les données retournées par ma requête font 59ko (je transferts 250
"entêtes" de mails dans un client mail)
J'utilise un Xeon 3Ghz (ce qui je suppose doit avoir un impact important
sur le temps de compression).

Sans compression
Moyenne de temps Connexion : 31 ms
Moyenne de temps d'excution : 109 ms
Moyenne du temps de transfert : 230 ms
-----
Moyenne du temps complet : 370 ms

Avec compression
Moyenne de temps Connexion : 31 ms
Moyenne de temps d'excution : 125 ms
Moyenne du temps de transfert : 30 ms
-----
Moyenne du temps complet : 186 ms

Donc c'est tout pile deux fois plus rapide.
ce qui est quand même très bien.

Etienne
Publicité
Poster une réponse
Anonyme