Problème de Performances avec RPC

Bonsoir à tous,

J'ai un problème de performances au niveau de l'envoi d'une liste d'objets de mon "serveur" gwt vers mon "client" gwt.

Je travaille avec Eclipse Galileo - JDK 6, la version 2.0.4 de GWT et la librairie graphique Ext-GXT (dernière version 2.2.0) + GWT Designer (last version of course).

Je décris en gros:

J'ai une interface graphique (un Grid GXT) censée afficher des records (des lignes) sur environ 8 colonnes (de types simples String, Date, Long)

J'ai écrit les 3 classes magiques permettant de mettre en place l'architecture RPC dans cette "application":
- RemoteService
- RemoteServiceAsync
du coté client
et l'implémentation - RemoteServiceImpl du côté serveur

Dans l'implémentation (RemoteServiceImpl):
J'effectue un appel vers un WebService par l'intermédiaire d'un proxy (classes Java générées depuis le WSDL via wsimport - une tâche Ant).
Je fais de la transformation d'objet vers des types propres à mon application GWT et je remballe le tout vers mon client...

Mon client réceptionne la collection d'objet au sein de son "listener" AsyncCallBack (je parle de sa méthode "onSuccess").

Le problème:
Le temps???

Imaginez 100 objets d'un type de classe ayant 8 attributs primitifs (genre de types: Date, String, Long).

L'appel du webservice WSDL devant retourner cette collection me retourne une réponse après 800ms (ça va - et j'ai bien les 100 records...).
Mon traitement de transformation (Objets de Type(1) vers Objets de Type(2)) me prend 150ms (ça va aussi).

- Je suis toujours au niveau de mon "serveur" GWT

Par contre, l'évènement "onSuccess" de mon AsyncCallBack n'est 'réveillé' qu'après pas moins de 8 secondes ???????????? (pour 100 records)

Enfin, le fait d'afficher les 100 records prend encore au moins 2 secondes du côté client.

Ma question:
Que faire?


Le webservice que j'appelle se fait sur un serveur Tomcat local au-travers d'un ESB (démarré également en local)
Mon application GWT est lancée en local suivant les paramètres par défaut du "Launcher GWT Application" (serveur Jetty en local)

Tant que je suis dans la couche "serveur", le fait de ramener les 100 records depuis ce webservice ne dépasse pas la seconde => Ok Mais le réveil du client (appel asynchrone oblige) ne se fait que 8 sec plus tard !?



Merci d'avance pour vos idées

Serait-ce un problème de sérialisation?
Pourtant j'implémente les deux interfaces:
- Serializable (java.io)
- IsSerializable (gwt)

Ok, je viens d'avancer sur le problème...

Déjà, je suis passé à GWT 2.1.0.
Ensuite, j'ai déployé mon application sur un serveur tomcat

et là, effectivement, les performances sont au rendez-vous (enfin, dans les limites du raisonnable).

En résumé:

Utilisation 1 de mon application GWT
Quand je sélectionne mon projet GWT, et que j'appelle le popup menu d'Eclipse - en mode développement - je sélectionne
"Run As GWT Application"

Le plugin Google GWT me lance une application Swing avec un serveur local Jetty où il place mon application GWT

Les perfs: ramener 100 records depuis un web service, transformation dans des objets qui me sont propres et affichage dans une grille avec de belles icônes = 8 secondes

Utilisation 2 de mon application GWT
Quand je d'exécute une compilation GWT et que je génère un "war file" que je déploie ensuite sur un serveur tomcat; les perfs: pour la même requête, j'affiche mes 100 records en un peu plus d'une seconde.

Pourquoi une telle différence de perfs entre mon utilisation 1 et mon utilisation 2 ?

Personnellement, j'ai observé des différences de performances lors de l'utilisation de Google Maps.

Pour ma part, l'application déployée était également plus rapide que la version de dév.

J'explique ces différences de la manière suivante.

En mode développement et depuis GWT2.0, le code Java n'est plus compilé en javascript. Le code java manipule directement le DOM du navigateur grâce au plugin GWT installé dans le navigateur, plugin qui communique avec Eclipse pour permettre justement le débuggage en pas à pas.

En mode production (une fois le code Java compilé par GWT en javascript), c'est ce code javascript qui manipule le DOM de la page web.

J'imagine que l'implémentation Java qui ne sert qu'au développement n'a pas été très optimisé (puisqu'elle ne sert qu'en dev) contrairement au Javascript qui lui est en situation réelle.

C'est ce que j'en ai déduit. Je ne prétend pas que c'est la réponse mais je ne vois pas ce que cela pourrait être d'autre. Donc si vous avez d'autres idées, elle sont les bienvenues.