Une latence excessive sur votre application GWT/GAE? pas de panique, c’est “peut-être normal”! Pour toi lecteur, je te partage l’info !

Je développe en ce moment une petite application WEB basée sur les technologies GWT et GAE.

Lors de mes récents tests en environnement de “production”, j’ai constaté une réactivité faiblarde à la première interaction avec mon application. Etant donné que l’ensemble de mes fonctions appelées interagissent toutes avec le datastore, et ayant résolu le problème avant d’aller plus loin, je ne peux pas réellement affirmer si c’est l’accès au datastore qui est en cause (les requêtes sont plutôt simples) ou si c’est le serveur applicatif).

Mais une fois passé cette première requête lente…ça envoie de la patate. Et c’est surtout taillé pour monter en charge de manière totalement transparente (avantage du GAE).

Bref, en gros maniaque des performances…je ne pouvais laisser mes futurs utilisateurs adorés avec ce temps d’attente affreux (entre 6 à 8 sec) et surtout trouver l’origine du problème. Ci dessous le message visible dans les logs de GAE (interface admin).

#10-22 12:19PM 12.330 /topsecret/log 200 6352ms 7993cpu_ms 176api_cpu_ms 0kb Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3,gzip(gfe)
78.228.96.116 - - [22/Oct/2009:12:19:18 -0700] “POST /topsecret/log HTTP/1.1″ 200 132 “http://topsecret-beta.appspot.com/topsecret/0D01E7FF5AD6B94356E41E31751A053C.cache.html” “Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3,gzip(gfe)”

Google App Engine optimise ses webfarms. Les ressources allouées pour chaque application est également gérées. Je ne sais pas exactement ce qu’il s’y passe derrière, mais une application tombe en “veille” au bout d’un certain temps (5-10 minutes) s’il n’y a aucune activité (pas de requête).

Voici le test que j’ai réalisé:

• J’ai attendu au moins 10 min pour placer l’application en veille.
• Une personne s’est connectée à l’application et a appelé une fonction (en observant ce phénomène de latence).
• Je me suis connecté à l’application juste après (1 min) et j’ai observé aucune latence sur la même fonction appelée.
• CQFD.

Cette latence ne sera donc pas observée si l’application est périodiquement utilisée. C’est à dire qu’il faudra que GAE réalise une consommation CPU toutes les 5 ou 10m pour éviter de tomber en mode “veille”, sinon le réveilleur observera ce phénomène de “lenteur”.

Il me semblait intéressant de partager cette information.

Si toi, cher lecteur, tu connait plus précisément le fonctionnement de “veille” de GAE, il serait généreux de ta part de nous éclaircir la lanterne. Merci d’avance.

Merci de m’avoir lu.

RL.

Google App Engine

Pour tous ceux qui aime le développement web, mais qui sont rebutés à l’idée de déployer leur application, Google lance son Google App Engine qui supporte désormais le JAVA. Il n’est, bien sûr, pas là par hasard, il vise à étendre l’utilisation de GWT, véritable combattant de la guerre des plateformes client riche avec SilverLight, Flash, JavaFX, Flex, Echo2, YahooUI!, etc…

Un plugin eclipse est disponible comprenant 3 boutons

• créer une application (GWT),
• compiler son application,
• déployer son application sur GAE.

Pour rappel, GAE vous fournit le serveur avec une scalabilité impressionnante. Il supporte jusqu’à 400 requêtes secondes sans une perte de performance (quota du compte gratuit). Au delà, si vous voulez plus, vous devrez vous acquittez de certains frais supplémentaires). De plus, il vous est possible d’utiliser soit une base de données relationnel soit le datastore de google dont ils fournissent l’API.

Il est clair que Google peut facilement imposer son GWT en offrant une plateforme largement au dessus de tout ce qui existe déjà et sans débourser le moindre centime. A ma connaissance, il n’existe aucun hébergeur sur le marché capable de faire mieux. Son slogan est véritablement évocateur: “Easy to build, easy to maintain, easy to scale”

Si vous voulez débuter, je vous envoie sur ce mini-tuto de prise en main pour installer l’environnement, le plugin, créer votre compte Google App Engine et faire votre premier déploiement. En 30 min, c’est réglé.

http://www.programmez.com/tutoriels.php?tutoriel=99&titre=Ma-premiere-application-Google-App-Engine-Java-dans-le-cloud-computing

PS: à noter qu’il faut demander la prise en charge de JAVA sur votre compte.

Vous recevrez l’erreur suivante lors de votre déploiement:

java.io.IOException: Error posting to URL: http://appengine.google.com/api/appversion/...
400 Bad Request
Invalid runtime specified.

Unable to upload app: Error posting to URL: http://appengine.google.com/api/appversion/...
400 Bad Request
Invalid runtime specified.

Pour corriger cela, rendez-vous sur la page suivante et postulez: http://appengine.google.com/promo/java_runtime

Merci de m’avoir lu.

Romain LAFOND.

Tout d’abord, dressons un petit schéma de ce qui se trame aujourd’hui lorsque vous naviguez sur internet.

Connexion Internet de chez vous à JDK CC

Actuellement, lorsque que vous vous connectez à votre « box » pour aller naviguer sur Internet, votre FAI (Orange, Free, Alice, Darty, Neuf, etc..) vous attribue une adresse IP. C’est cette adresse IP qui permettra, en cas de problème, de vous retrouver.

Dans le cas d’un adressage statique, vous avez toujours la même IP, mais bien souvent les FAI vous fournissent une adresse IP dit dynamique, c’est-à-dire, qui change à chaque reboot de la « box ». Dans ce cas, ne vous croyait pas hors d’atteindre, les FAI archivent et savent quand et à quel abonné une adresse IP a été fournit. Si vous commettez une infraction, la brigade de police judiciaire BRCI (Brigade de Répression de la Criminalité Informatique) sera vous retrouver. Comment ? Légalement, il est obligatoire pour chaque serveur de conserver ses logs pendant plusieurs années. C’est grâce à ses logs (avec l’IP) qu’ils vous retrouveront sans problème.
Bref, sur internet à chaque fois que l’on fait quelque chose (clic, téléchargement, soumission d’un formulaire), on laisse une empreinte. De plus, sur le schéma, on voit bien que tout passe par le FAI. Il sait absolument tout de ce que chaque internaute fait.

Une solution

Si l’on veut rester incognito (sans passer par la box de son voisin), il faut passer par un proxy anonyme pour « masquer » l’IP FAI qui permettrait de nous retrouver. Lorsque l’on se connecte à un site, nous n’avons plus comme empreinte l’IP de notre FAI, mais l’IP du proxy par lequel on passe. On devient donc impossible à retrouver.

Pourquoi un proxy anonyme ? Et tout simplement pas un proxy tout court ? Un proxy log, c’est une obligation. Si l’on veut vous retrouver, il suffira d’aller voir dans les logs du proxy pour récupérer votre IP du FAI. Un proxy anonyme par principe ne log pas, c’est-à-dire qu’il s’engage à désactiver ce mécanisme. Mais le fait-il vraiment ? Voilà une autre question.

Pratique (avec firefox).

Allons sur le site http://www.localiser-ip.com (il géo-localise votre ip).

Sans proxy anonyme (IP FAI)

Voyons maintenant le site proxy-list.org qui propose des proxys anonymes.

Référencement des proxys anonymes

La configuration sous firefox pour passer par un serveur proxy: “Outils > Options > (onglet avancé et réseaux) > paramètres”.

Configurer firefox pour un proxy anonyme

Et voyons maintenant le résultat, nous sommes en plein Nigeria

Géolocalisation IP avec un serveur proxy anonyme

A utiliser avec précaution. Merci de m’avoir lu.

Romain LAFOND

Je remonte un problème qui m’a paru personnellement assez fourbe. Il concerne un bug (ou pas?) lors de la création d’une base de données alimenté par un fichier de conf Hibernate.  Bien entendu, je fournis la solution…

On obtient la sortie d’erreurs suivante (il ne veut rien savoir, la table “USER” ne lui plaît pas):

24 mars 2009 22:54:45 org.hibernate.tool.hbm2ddl.SchemaExport create
GRAVE: Unsuccessful: create table USER (UID integer not null, LOGIN varchar(12) not null unique, PASSWORD varchar(12) not null, EMAIL varchar(255) not null, REGISTRATION-DATE timestamp not null, STATUS integer not null, primary key (UID))
24 mars 2009 22:54:45 org.hibernate.tool.hbm2ddl.SchemaExport create
GRAVE: Erreur de syntaxe : Encountered “USER” at line 1, column 14

Avec comme configuration :

<class name="core.User" table="USER">
        <id name="uid" column="UID">
            <generator class="increment"/>
        </id>
        <property name="login" column="LOGIN" not-null="true" unique="true" length="12"/>
        <property name="password" column="PASSWORD" not-null="true" length="12"/>
        <property name="email" column="EMAIL" not-null="true" />
        <property name="registrationDate" column="REGISTRATION-DATE" not-null="true" type="timestamp"/>
        <property name="status" column="STATUS" not-null="true" type="integer"/>
</class>

Problème bête (une histoire de nommage…):

Le problème vient de la définition de l’attribut “column”.  Hibernate ne supporte pas les majuscules en nom de colonne. C’est valable également pour les tables.

Solutions (si j’avais su…):

• écrire les tables en minuscule,
• rajouter des back-quotes –> ` <– (comme ceci: column=”`LOGIN`”)

En espérant vous avoir aidé !

Romain LAFOND.

Il faut l’avouer, en tant que développeurs, nous avons acquis des compétences particulières nous octroyant la merveilleuse capacité de…créer. Ça fait un peu « dieu » dit comme ça. Mais créer quoi au fait ? Nous ne sommes pas vraiment ce que l’on appelle « des artistes ». Ou du moins, pas au sens des beaux arts comme on l’entend. Nos outils ne sont pas aussi nobles qu’un pinceau ou qu’un crayon. La création se fait avec des centaines voire des milliers de lignes de code Et oui…c’est nettement moins sexy dit comme ça, mais on aime ça ! Mais quelque part, il y a une graine d’artiste qui sommeille en nous avec un style, par contre, beaucoup plus…geek !

Au-delà de la technique,  ce qui importe le plus, c’est bien sûr la finalité (ce que l’utilisateur va bien pouvoir en faire et ce pourquoi il va l’utiliser). Son succès réside bien souvent dans son inventivité, identité, unicité et sa créativité dans la manière dont elle s’utilise (il faut que l’utilisateur y trouve un intérêt, sans quoi elle finit à la poubelle). Dans un monde où tout va vite, c’est l’idée qui est bien souvent la clef et non la manière de la mettre en œuvre.

De plus, compte tenu du contexte économique lié au monde d’internet, il est désormais possible de tirer profit de sa création. Un bon point pour nous, les geeks, faces aux artistes, les vrais. Comment ça ? Il y a deux solutions viables actuellement. La première étant de privilégier les micro-transactions en « commercialisant » son appli. à de très petit prix de l’ordre de 50 centimes d’euros/dollars (ex : iPhone store). La deuxième, surement la plus utilisée, est le recours aux revenus publicitaires (ce qui signifie déjà une orientation axée web). Sur le papier, ça n’a l’air de rien, mais cette modique somme multipliée par 50 000, 100 000, ou 500 000 utilisateurs permet de générer de vrais revenus. En vivre n’est pas usuel et n’arrive qu’à très peu de personnes (on pourra noter la réussite du projet ma-bimbo.com qui est devenu aujourd’hui une entreprise). Généralement, on en tire de petits bénéfices permettant de s’acheter une petite babiole. Mais l’argent, ce n’est pas la finalité recherchée, mais disons que c’est le petit « bonus-track ». Et ce n’est déjà pas si mal que ça !

Adepte des projets « perso », c’est à foison que je me suis exercé dans ma jeune carrière de « développeur ». De manière générale, j’ai toujours réalisé mes projets en fonction des compétences que j’avais à ce moment là. Depuis, j’ai constaté que plus j’accroissais mes compétences, plus j’avais de nouvelles idées de projet aussi folles les unes que les autres. Le hic dans tout ça, c’est véritablement le problème du temps. Impossible d’aller jusqu’au bout d’un projet. Entre l’école, les sorties, les vacances, c’est un hachage continue qui tend à stopper un projet. Depuis le début de mon master MIAGe, j’ai commencé un projet d’une envergure plutôt conséquente visant à développer une plateforme de poker. Ayant touché du doigt plusieurs domaines compliquées, je ne suis même pas arrivé à la moitié de mes objectifs. Beaucoup trop long pour un seul homme. J’étais aux environs de 500 heures de développement. Ce qui fait 62.5 jours homme. Malheureusement, depuis, j’ai acquis de nouvelles compétences rendant quasiment obsolète une grosse partie du moteur de jeu. Il y a tant à refaire par rapport à l’existant : programmation par les patrons, gestion de la persistance, web services, server push, etc.  De plus, mes goûts ont changé et ma vision de la « bête » a véritablement évoluée. D’autant plus que je me suis sensibilisé à des problématiques beaucoup plus évidentes et pérennes selon moi (maintenance, vélocité, robustesse, ergonomie, et j’en passe…). C’est pourquoi, pour la première fois de ma vie, j’en suis à écrire les spécifications détaillées avant de commencer le cycle de développement. Et j’espère cette fois-ci pouvoir arriver au bout. C’est devenu, au fil du temps, beaucoup plus qu’un simple projet, c’est un mélange de défi, de curiosité et de volonté de ne pas rester sur un gout d’inachevé. Sachant que cela reste évidemment un plaisir d’occupation.

Le développeur assume à 100% sa pulsion créative et son plaisir réside aussi bien dans la réalisation que dans la satisfaction d’y parvenir. Généralement, les projets sont longs, se segmentent dans le temps et se font très souvent sur le temps libre…d’où le surnom « développeur du dimanche ». Au final, ce qui est le plus drôle, c’est souvent la période où le projet naît. C’est généralement des tas d’idées plus  farfelus les uns que les autres. Ca fristouille dans tous les sens !
Il y également ceux qui pense inventer quelque chose de « révolutionnaire », ce développeur fou voudra alors concrétiser cette envie et vivre son rêve jusqu’au bout (on pourrait comparer cette envie à celle de créer une entreprise, ou d’un inventeur et de son invention. Tous les deux sont persuadés que cela va marcher !).

Que ça soit par envi ou par intérêt, le développeur « fabrique » ses programmes ! Utile ou pas utile, cela n’a aucune importance. La finalité est de se faire plaisir. Développer, coder, c’est une vrai passion. Et à ce titre, ça vaut le coup de la vivre à 200% ! N’en n’ayez pas honte !

Romain LAFOND

Vous voulez changer dynamiquement la couleur d’un de vos Clip ou MovieClip en Flash à partir d’Action Script 3.0 (AS3).

Cela se fait en 3 lignes de code:

/* création du Clip - MovieClip */
var monClip:Rond = new Rond();
this.addChild(monClip);
 
/* on change ici sa couleur */
var newColorTransform:ColorTransform=monClip.transform.colorTransform;
newColorTransform.color=0x330000; // ici le code couleur FF330000
 
monClip.transform.colorTransform=newColorTransform;

Voilà !

Romain LAFOND

Cycle de vie d’une Servlet

Le cycle de vie d’une servlet est assuré par le conteneur de servlet (Tomcat, Jetty, Glassfish, etc..). Ainsi afin d’être à même de fournir la requête à la servlet, récupérer la réponse ou bien tout simplement démarrer/arrêter la servlet, il implémente l’interface (servlet) permettant de réaliser :

1. Le serveur crée un pool de threads auxquels il va pouvoir affecter chaque requête  (ce pool est limité dans la configuration du serveur, pas plus de x threads exécutant la servlet)
2. La servlet est chargée au démarrage du serveur ou lors de la première requête
3. La servlet est instanciée par le serveur  (1 fois)
4. La méthode init() est invoquée par le conteneur
5. Lors de la première requête, le conteneur crée les objets Request et Response spécifiques à la requête
6. La méthode service() est appelée à chaque requête dans une nouvelle thread. Les objets Request et Response lui sont passés en paramètre. Une servlet est donc accessible par plusieurs threads en même temps.
7. Grâce à l’objet Request, la méthode service() va pouvoir analyser les informations en provenance du client
8. Grâce à l’objet Response, la méthode service() va fournir une réponse au client (puis ferme la connexion)
9. La méthode destroy() est appelée lors du déchargement de la servlet, c’est-à-dire lorsqu’elle n’est plus requise par le serveur. La servlet est alors signalée au garbage collector (communément francisé en ramasse-miette)

Geler une requête

Dans le but de « geler » la réponse du coté serveur, on interrompt le traitement de la réponse en « bloquant » le thread (à l’aide d’un verrou en attente sur une ressource - autre que la servlet sinon toutes les requêtes seront bloquées). Autre remarque, les spécifications servlets interdisent d’utiliser un Thread.sleep() dans une servlet. En effet, une servlet est un objet partagé par plusieurs clients (donc plusieurs Threads).

Dans l’exemple ci-dessous, on désire toujours récupérer la 200éme ligne. La servlet se met en attente – wait() – s’il n’y a pas cette dernière.

try{
   synchronized ( chatMessages ) {
      while ( chatMessages.size() < 200 ) try {
         // on gèle la connexion tant qu’il n’y a pas eu d’événement
         chatMessages.wait();
      }
      repondre(chatMessages.get(200));
   }
}catch ( InterruptedException e ) {
   repondre("Server interrupted. Chat Session Closed.");
}

Lorsqu’on client envoie un message, il ajoute ce message à la ligne des messages. Puis, on réveille alors tous les threads endormis (en attente d’un message). Lorsqu’il se réveille, il exécute donc l’instruction juste après le wait()), c’est à dire return(chatMessages.get(200)); qui retourne au client la 200éme ligne, libère le thread et ferme la connexion.

Ci-dessous les instructions de traitement lorsqu’un client envoie un message.

synchronized ( chatMessages ) {
    chatMessages.add("je suis la 200eme ligne...");
    chatMessages.notifyAll();
}

Problèmes

Malheureusement, cela signifie qu’un thread est alloué pour chaque requête gelée (type “server push”). Généralement les serveurs web (Tomcat, Jetty, etc..) ont un nombre limité de threads autorisés (sinon, il serait très facile de faire crasher un serveur). Une fois ce cap atteint, il refuse d’accepter une nouvelle connexion, donc de lancer un nouveau thread. Toute nouvelle requête est simplement ignorée. Le serveur pense qu’il est sous une charge importante, alors qu’il ne l’est pas du tout.

Il est toujours possible de modifier le nombre de threads disponibles pour une servlet, mais ce n’est pas une bonne solution. Aujourd’hui, il existe quelque chose de beaucoup plus robuste et qui supporte très bien la charge. Ça s’appelle Comet. Il est implanté dans Jetty sous le nom de « continuations » ou « CometProcessor » sous Tomcat.

L’idée derrière la continuation est bien sûr de geler les connexions (comme on l’a vu précédemment). Sauf que cette fois-ci on va employer une API de bas niveau pour gérer les entrées/sorties dans le but de n’avoir qu’un seul thread qui gère les requêtes « server push » (au lieu du schéma “1 requête = 1 thread”).

Jusqu’à l’API 3.0 Servlet, le principe de continuation n’existait pas. Chaque conteneur de Servlet le faisait à sa sauce.
On peut citer les deux plus connus :

• Jetty Continuations
• Tomcat Advanced I/O Support (CometProcessor)

ps: l’API Servlet 3.0 est encore en bêta.

Romain LAFOND

Problématique

Pour garantir ce transport, des règles ont été établies. Les plus gros routeurs, véritable piliers du trafic mondial, rencontrent tous le même problème : la taille de leur table de routage. Si cette dernière devient trop volumineuse, l’accès aux entrées croît très vite et le temps de traitement des paquets (au final, de la requête) augmente. Si on multiplie ce temps par le nombre de routeurs traversés, alors la latence devient énorme (plusieurs secondes)…

Pour remédier à ce problème, le routeur a pour tâche d’effacer périodiquement les entrées les plus anciennes/moins utilisées dans sa table de routage. Il doit adapter ce temps de suppression en fonction de sa capacité à traiter les informations (configuration matériel) et du trafic subit (nombre de paquets à router/temps).

Le NAT, par exemple, a lui aussi une table avec une durée de vie limitée. il en existe surement d’autres…

Tout ça pour dire qu’une requête ne peut plus forcement revenir là d’où elle vient si elle est bloquée trop longtemps. C’est pourquoi, dans la plupart des systèmes, il existe un système de timeout permettant de ne pas attendre indéfiniment la requête. Il est appliqué par tout le monde. Il représente le temps maximum qu’une entité (exemple : un client web) est prête à attendre avant qu’une réponse de l’entité distante dont il attend cette même réponse, lui parvienne. Au-delà de ce temps, on soulève donc l’erreur timeout, ou en français « temps d’attente dépassé ».

Explication

En pratique, on ne devrait jamais laisser notre server push maintenir une connexion plus d’une minute. Le timeout est inévitable sur internet… C’est pourquoi, on ruse en employant la technique du « connexion refresh ». Détaillons.

Schéma du principe du connection refresh

Le connection refresh est une technique simple visant à forcer le rafraichissement de la requête coté serveur.

Par exemple, si toutes les 40 secondes, je n’ai pas d’événements à notifier,  afin d’éviter que le client parte en timeout,  je réponds quand même au client avec « n’existe pas » et je ferme la connexion. Le client, de son coté, va simplement ré-établir une nouvelle connexion qui durera également 40 secondes si aucun événement se produit. Et ainsi de suite…Avec cette technique, on évite donc ainsi les désagréments dus au transport « physique » de notre requête (paquets IP).

Conclusion

Il faut l’avouer, cette technique reste très proche du « polling ». C’est pour cela que la technique du server push est également appelée « long polling ».

On n’a pas réellement trouvé mieux à l’heure actuelle, mais elle est beaucoup plus efficace en termes de latence et de charge qu’une répétition de demande (scrutation) toutes les x secondes.

Romain LAFOND

On va tâcher d’expliquer la différence entre server push et comet. Nous verrons que ce n’est pas tout à fait la même chose, bien qu’ils soient, aujourd’hui, très souvent associés l’un à l’autre.

Nous allons tout d’abord schématiser:

1. le cycle de vie d’une requête HTTP standard
2. le cycle de vie d’une requête HTTP type server push (avec une API bloquante)
3. idem mais avec une API non bloquante

1. Le cycle de vie d’une requête HTTP standard

Cycle de vie d'une requête HTTP standard

Ce schéma décrit le cycle de vie d’une requête http standard. La requête est envoyée, récupérée par le serveur (la traite dans un thread), répond immédiatement au client, ferme la connexion et libère le thread. On a donc 1 requête = 1 thread.

2. Le cycle de vie d’une requête type server push avec une API bloquante

Cycle de vie d'une requête type server push avec une API bloquante

On implémente le système de server push avec une API bloquante (le plus facile à mettre en place). Lorsque le serveur reçoit la requête, elle est prise en charge dans un thread. Au lieu de retourner la requête réponse, on ne retourne rien volontairement. C’est à dire qu’on gèle la connexion en attendant un événement coté serveur.

Par exemple, un client a une liste de messages non lus. S’il n’a aucun message, alors on attend:
messagesNonLus.wait();

Lorsque le serveur récupère un message d’un autre client pour le client en attente:

utilisateurEnAttente.messagesNonLus.add(new Message(« JDK Coding Club !»));
utilisateurEnAttente.messagesNonLus.notify ();

Le notify() a pour effet de réveiller le thread qui était verrouillé sur la liste. A ce moment, le thread récupère les messages non lus, et les envoie au client et se termine.
On est bien dans un schéma 1 requête = 1 thread.

3. Le cycle de vie d’une requête type server push avec une API non bloquante

Cycle de vie d'une requête type server push avec une API non bloquante

Avec l’API non bloquante, on s’approche du modèle d’architecture « Comet » (comet pattern).

En effet, lorsqu’un client envoie une requête, le serveur lance un thread pour la prendre en charge. Jusque là, on suit le même schéma que les deux précédents.
Mais, cette fois-ci on va dé-sérialiser la requête et la stocker (éventuellement l’associer à un client - utilisateur par exemple) pour pouvoir la récupérer ultérieurement.  On peut libérer le thread. Ensuite, on ne fait rien (la requête est gelée) jusqu’à ce qu’un événement arrive et nécessite d’être transmis à un client ou plusieurs clients.

Dans notre cas de messagerie, lorsque le serveur reçoit un message pour un utilisateur en attente de ses messages non lus, il récupère tout d’abord la requête gelée « server push » du client en attente, il y insère le ou les messages non lus (on remplit le « payload » de la requête). On sérialise la requête, puis on envoie la requête au serveur. Et enfin, on ferme la connexion.

Définition Comet

Le terme Comet n’a pas de réel définition, pour preuve sur wikipedia personne n’arrive à se mettre d’accord. Il a été inventé par Alex Russell, un des créateurs du framework Cometd (dojo), dans son blog avec l’article Comet: Low Latency Data for the Browser.
Mais pour sûr, il désigne avant tout un modèle de patron web (j’insiste pour le web) permettant de transporter, via le protocole HTTP, des événements asynchrone du serveur vers le client en maintenant une latence très faible. Il s’implémente suivant deux points importants.

Premièrement, il faut absolument éviter le problème de blocage entre le client et le serveur (limitation à deux connexions). C’est pourquoi, au lieu d’utiliser plusieurs requêtes gelées pour un même client dans une application web, on n’instaure qu’un seul service qui ne fait que gérer les événements entre le serveur et les clients. C’est là qu’on utilise le principe du server push au travers des techniques de « long polling » (anciennement appelée « slow polling »).

Deuxièmement, le but est d’établir des connexions HTTP persistantes (« long-lived HTTP connections »). Même si d’un point de vue purement technique, ce n’est pas vraiment du « mode connecté », le comportement final obtenu est quand même semblable. Pour cela, il faut utiliser un serveur web/conteneur de Servlet qui autorise les connexions non bloquantes. Il y en a plusieurs, j’en cite trois des plus connus :

• Jetty avec Continuations
• Tomcat avec CometProcessor
• Grizly avec CometHandler

Pourquoi utiliser des API non bloquantes ?

On peut très bien faire du server push avec un simple serveur tomcat (API bloquante). Pour cela, il suffit de geler le thread de la servlet avec un « wait() » sur un objet, de répondre lorsque le serveur en a besoin en notify() ce dernier.

Le problème se situe au niveau de robustesse de l’application lors de la montée en charge.

2000 utilisateurs avec chacun leur requête server-push gelée par le serveur correspond également à 2000 threads.  Le second problème, c’est qu’il y a un nombre de thread maximum (config server.xml) pour chaque Servlet. On pourrait, certes, le modifier, mais que ce passe-t-il si un petit malin envoie 2000 requêtes trafiquées d’un coup…Je crains qu’il finisse par faire tomber le serveur.

Alors qu’avec une API non bloquante, nous n’avons qu’une collection de 2000 requêtes. Là est toute la différence.

Reverse Ajax ?

Le terme a été lancé par les auteurs du Framework DWR (Direct Web Remoting). Concrètement, le Reverse-Ajax est l’ensemble des techniques plus ou moins proche de comet permettant de faire de la notification sur le web.

• Polling (scrutation)
• Comet / Slow polling / Long polling (ou encore l’utilisation des “long-lived HTTP connections”)
• PiggyBack

Ce dernier consiste à intégrer dans une requête de réponse une notification, de la sorte que la réponse et la notification sont envoyées en même temps.

Conclusion

Le server push permet d’envoyer des données à un client lorsque le serveur le décide (sans que le client ne le demande). C’est le principe de la notification pour le web.
Comet est un patron visant à bien implémenter le principe du server push. Et cela en partie du à l’arrivée des API non bloquantes.
En réalité, le server push est souvent associé au principe de comet, mais techniquement, ça n’a rien à voir.

Romain LAFOND

]]> http://www.jdkcodingclub.net/2008/11/definition-comet/feed/ http://www.jdkcodingclub.net/2008/11/les-mecanismes-du-server-push-les-problemes/ http://www.jdkcodingclub.net/2008/11/les-mecanismes-du-server-push-les-problemes/#comments Wed, 12 Nov 2008 20:57:14 +0000 Romain LAFOND http://www.jdkcodingclub.net/?p=88 Dans ce billet, nous allons soulever les problèmes liés à la mise en place du mécanisme de Server Push dans une application web.

En reprenant le même exemple abordé dans l’article (http://www.jdkcodingclub.net/2008/11/definition-principe-polling-scrutation/), notre client envoie une requête pour récupérer sa nouvelle ligne :

http://mon.chat.app/getChatLine?idx=200

Cependant, au lieu de retourner « n’existe pas » (si la ligne n’existe pas), le serveur ne répond pas volontairement. Cela a pour effet de donner l’impression que le serveur est lent étant donné qu’il ne répond pas. Mais, cela fait parti du mécanisme. Je m’explique. Lorsque la 200éme ligne est envoyée par son interlocuteur, cela réveille le serveur, il complète la requête (en y insérant le message) et fini par envoyer la 200éme ligne au client.

Avec ce mécanisme, le client n’a pas besoin de continuellement demander à récupérer la dernière ligne. Il la demande 1 fois et il attend que le serveur lui donne.

L’idée est pourtant simple, mais malheureusement le protocole HTTP n’a pas été pensé de cette manière. Cela va donc nous poser un certains nombres de problèmes.

Flush

Le protocole HTTP ne supporte pas bien le flush. Inutile donc de vouloir garder la connexion ouverte et de « pousser » les données. Ce n’est pas du streaming, pourtant cela marche, mais pas très bien lorsque le client est derrière un routeur qui passe par un proxy qui lui-même passe par un autre chemin. Bref, HTTP ne supporte pas le flush.

Timeout

Lorsqu’un navigateur attend une ressource d’un serveur et que celle-ci tarde à venir, le navigateur affiche la page du « timeout » au bout d’un certain temps. Pour lui, le serveur ne répond pas (pour diverses raisons).  Mais il n’y a pas que le client et le serveur… Entre les deux, les proxy, les routeurs et autres passerelles ne savent pas faire la différence entre une connexion lente (où le timeout est justifié) et une connexion maintenue (gelée ou freezed) volontairement par un serveur (rappelons qu’il ne répond pas intentionnellement). Il faut donc prendre en compte qu’une connexion gelée ne peut pas l’être éternellement.

2 connexions maximum

La majorité des navigateurs ne peuvent établir que 2 connexions simultanées vers un domaine (exemple : « www.chat.app ». S’il y en a 3, alors la troisième requête est placée en file d’attente jusqu’à ce que le serveur est fini de traiter l’une des 2 premières.

Une requête maintenue en server push consomme déjà la moitié des connexions possibles… Dans l’exemple d’un chat, on utilise à 100% les 2 connexions possibles (une pour le mécanisme de server push et l’autre pour envoyer un message). A noter que s’il y a 2 requêtes gelées simultanées sur le même serveur, le client sera bloqué et ne pourra plus dialoguer avec le serveur. Il devra donc attendre la notification d’un événement ou que le serveur relâche un des 2 requêtes gelés s’il n’y en a pas.

Google Maps fonctionne de cette manière pour récupérer plus vite les images d’une carte satellite. Pour pouvoir bénéficier de plus de 2 connexions, il se connecte à khm1.google.com, khm2.google.com, mt1.google.com etc… Il cumule donc les connexions. La limitation est donc un faux problème car des solutions simples existent.

Sur notre application, on pourra donc avoir un sous domaine « serverpush.chat.app » gérant les requêtes de type Server Push afin d’éviter le blocage de requêtes entre le client et le serveur et d’assurer ainsi une meilleure performance et robustesse de l’application.

Résumé

Pour résumer, on peut dire que le protocole HTTP  ne favorise pas vraiment l’implémentation du mécanisme de server push dans une application web. Bien heureusement, nous verrons que des solutions existent. Cependant, elles se contentent essentiellement de contourner les problèmes (flush, timeout et limitation du nombre de connexions). L’utilisation du web change, le web change, en attendant une nouvelle version du protocole HTTP, il faudra bien bricoler !

Romain LAFOND