performance serveur pour form

[LeHibou2]

Bonjour à tous,

Est-ce que

Code javascript :

1
2
3
4
5
6
 
var html = '<div class="lola"><table><tr>';
html += '<td class="lola">' + entry['nom'] + '</td>';
html += '<td class="lola">' + entry['prenom'] + '</td>';
html += '<td class="lola">' + entry['famille'] + '</td><tr></table>';
madiv.append(html);

a une incidence quelconque sur la charge serveur par rapport à une table habituelle :

Code html :

1
2
3
4
5
6
7
8
9
10
 
<div class="lola">
<table>
<tr>
<td class="lola2"><input type="hidden" value="nom"/></td>
<td class="lola2"><input type="hidden" value="prenom"/></td>
<td class="lola2"><input type="hidden" value="famille"/></td>
<tr>
 
</table>

La table fait quelques kb mais ce qui m'intéresse, c'est la charge nécessaire json vs html. Même si la diff est de 0.01% de bande passante, je suis intéressé.
Parce que firebug me montre le poids du fichier, soit, mais au niveau serveur, ça donne quoi concrètement ?

Un avis ?

Merci à vous,

LeHibou2

[LeHibou2]

Ma syntaxe ressemble à du mustache.js sans l'utiliser.

Cela est dommageable ?

[NoSmoking]

Bonsoir,
ta première écriture fait 240 octets, la deuxième 220, la deuxième gagnera mais le plus important est de voir la cohérence de l'ensemble, quel est l'intérêt de construire le code coté client ???

[LeHibou2]

Moins de charge cpu et bande passante (json) côté serveur ?

A l'instar de Closure template, que je vais bientôt intégrer à mon site web.

En clair, je ne veux faire transiter que les données de base et laisser le client les reconstruire correctement sur son poste.

[Bovino]

Charge CPU et bande passante, ça n'a rien à voir...
Mais qu'il s'agisse de l'un ou de l'autre, je doute que tu atteigne les limites proposées par un hébergeur !

Ensuite, la question n'est pas de savoir si tu gagneras un micro-octet ou pas, c'est plus de savoir qui est fait pour quoi !
Or de ce point de vue, la génération du HTML, c'est l'affaire du serveur. Construire sa page côté client est un non sens !

[LeHibou2]

Non, ce qui est un non-sens c'est de le faire "blindfolded" comme l'a fait twitter.

Il y a des parties qui peuvent être générées par le client à mon humbe avis pour limiter justement la bande passante. D'autres, server-side pour l'impression de vitesse.

Par exemple, j'ai un fichier json dans un html (pour des raisons spécifiques de sécurité traitée par le serveur) qui ne pèse que 27b.

Un formulaire html tout nu pèse 640b ici.

Si on a 800.000 visites uniques/j, cela fait une sacrée différence, car cette même différence s'applique à tout le site (plusieurs milliers de pages).

Evidemment, sur le blog de Mme Michu qui parle de ses furoncles, c'est inutile; Mais sur un site à fort trafic et contenu dynamique, chaque b de gagné est cela en moins à investir dans un serveur/offre plus puissante.

Bien sûr que cpu != bande passante. Mais sur un serveur les deux sont liés et il faut, AMHA, faire attention à ces deux valeurs.

Donc sauf avis contraire et argumenté je vais laisser le client tracer le form et n'importer que le json.

[Bovino]

Par exemple, j'ai un fichier json dans un html (pour des raisons spécifiques de sécurité traitée par le serveur) qui ne pèse que 27b.

Un formulaire html tout nu pèse 640b ici.

Et la partie de script qui sert à transformer le JSON en HTML, elle est bien dans ta page non ? Elle pèse combien elle ?

[LeHibou2]

Client-side.

Entre temps, j'ai fait des mesures.

Son poids approche les 400b pour une requête serveur de 175ms en moyenne, sur la page, reconstruction comprise, au lieu d'une page de 200k et 800ms en moyenne pour une page complète server-side.

Si je fais le dessin server side avec un load, je me trouve aux alentours de 600ms en moyenne avec un poids de page de 150kb (plus léger car je ne recharge pas le css et autres, bien qu'ils soient cachés).

Les mesures de poids s'entendent hors cache.
Avec le cache, le poids de la page est ridicule,soit, mais le temps de réponse est toujours de 800ms en moyenne.