Comment optimiser une grosse application Javascript

[Sephi-Chan]

Bonjour,

Me revoilà pour une discussion qui me tient à cœur : la façon d'optimiser les grosses application Ajax, celles qui ne se rechargent pas du tout et qui sont donc très vulnérable à l'emballement dû à une consommation de mémoire (ou de CPU) trop importante et qui nécessite de fermer la page.

Comment se protéger contre ça ? Quels sont vos conseils en la matière ? Comment limiter la consommation de ressources de Javascript ? Etc.


Sephi-Chan

[phenix]

Qu'est-ce que tu entend par:

les grosses application Ajax, celles qui ne se rechargent pas du tout et qui sont donc très vulnérable à l'emballement dû à une consommation de mémoire (ou de CPU) trop importante et qui nécessite de fermer la page.

L'interface de la vallée des larmes est entièrement en Ajax et j'ai jamais de problème :heuuu:

[Anthor]

Quand tu arrives à des interfaces du type gMail qui nécessite de désactiver firebug par exemple.
Des applications qui modifient fortement le DOM et autres.

PS: Je ne sais pas ce que tu as mis dans vallée des larmes
PS2: Sephi décevant ! Je pensais que tu le lancerais un peu plus en profondeur :p ou avec des simples quotes

[Allwise]

Alors pour ma part, j'ai déjà fait une application assez costaud avec ExtJs et, à l'époque, une grande partie du code javascript responsable de la génération des écrans était renvoyée directement par le serveur. C'est à dire qu'au lieu de créer mes composants et de les inclure toutes dans mon .html, puis de les appeler côté client, le code des composants était renvoyé par le serveur par les requêtes Ajax et exécuté côté client.
J'avais fait ça dans le but "d'encapsuler" ( notez les guillemets ) du code que je considérais comme sensible côté serveur. Bon vu que j'ajoutais à ça une compression du code js qui le rendait illisible par le commun des mortels, en fait c'était pas trop la peine...

Ça avait un certain côté pratique. Côté optimisation, du coup je n'avais pas créé autant de classes que j'avais de composants customs ( un composant correspond en gros à un écran avec formulaires, boutons, grilles...), tout était exécuté à la volée côté client. En revanche, j'utilisais eval() qui est très gourmand mais ça ne se ressentait pas.
Je n'avais aucun problème pour maintenir le code js car bien que renvoyé par le serveur, il était isolé dans mes vues ( MVC powa ), donc mes vues étaient des fichiers javascript, comme elles auraient pu être des fichiers .html.
Considérer que l'affichage = javascript = vue @ MVC, je trouvais ça logique.

Pour le jeu que j'avais commencé à faire full ajax par contre, j'avais pris le parti de créer des classes pour mes trucs personnalisés, et de les instancier le moment venu. Laisser le langage client au client, et le reste au serveur ( en gros, il renvoyait juste les paramètres pour les classes & fonctions js ). Peut-être qu'au chargement de l'application ç'aurait été plus long, mais je pense qu'à l'utilisation il n'y aurait pas eu de problème de lenteur particulière sous prétexte que beaucoup de code javascript eut été exécuté auparavant.

Y a qu'à regarder la lib d'Ext, elle est énorme, des dizaines de composants, un fichier .js qui pèse + d'1 mo quand il n'est pas minimisé et ça prend pas trois plombes au navigateur pour le charger.

[NicoMSEvent]

Il faut retenir l'état dans lequel l'application se trouve (sauvegarde constant a chaque opération ajax) + éventuellement un événement périodique qui te permet de retenir les champs en train d'être complétés (a la manière de GMail avec sa mise en "brouillon" du mail en train d'être tapé, en cas de coupure.)

Je pense que mon jeu commence tout doucement à être "gros" point de vue ajax (parfois 3 cadres a mettre à jour simultanément + un updateur périodique pour le petit "chat" intégré)... je vais aussi suivre ce topic avec grand intérêt

Note : j'ai parfois un soucis avec un cadre qui ne se recharge pas (le timeout de 2sec est parfois dépassé sur les toutes vieilles machines), faudrait que j'analyse un peu plus pour trouver le moyen de "bloquer" plus longtemps l'interface pour ce genre d'update (seulement dans le cas ou c'est plus long que prévu)

[Roworll]

faudrait que j'analyse un peu plus pour trouver le moyen de "bloquer" plus longtemps l'interface pour ce genre d'update

La méthode Comet est peut être indiquée pour ce cas, le flux vers le serveur restant ouvert tant qu'il n'a pas renvoyé sa réponse (long polling). Le seul timeout à avoir est celui qui renvoie la requête au bout de X seconde de "non-réponse"
J'ai toujours hésité à l'utiliser sur mon serveur mutualisé cependant. Je ne sais pas si mon hébergeur verrait d'un bon oeil le fait que je garde ouverte une tripotée de connexions vers le serveur.

[NicoMSEvent]

tu veux parler du keep-alive d'apache?

je viens de tomber sur cet url sympa : http://performance.survol.fr/2008/04/kee...sistantes/

sur un mutualisé, c'est faisable? (via .htaccess ou autre?)

[Roworll]

Une petit article pour démystifier tout ça.

Je pense que le long-polling, c'est un truc à tuer le serveur en cas de mutualisé avec beaucoup d'utilisateurs.

[Sephi-Chan]

Tu as tout à fait raison pour la vue Javascript.
Le MVC de Rails repose là dessus. Cf. Ce screencast très intéressant.

J'enrichirais une fois chez moi.


Sephi-Chan

[QuentinC]

Il faut encore que le serveur supporte les requêtes HTTP longues... apparament apache en est incapable (selon l'article), donc il faut le faire en autre chose que php et il faut sûrement avoir un dédié (je ne connais pas d'hébergeur mutualisé de masse à un prix correct qui utilise autre chose que apache)