Discussion :

[ran_hery]

Bonjour à tous.

Mon application emploie des EJB session stateless (version 2.0) couplés avec une Architecture MVC Spring. Le serveur d'application est JBoss 3.0.3 et la base de données Postgresql 8.1.

1) J'ai lu quelque part (Je me souviens plus du site) que le fait de coupler Spring MVC avec les EJB 2.0 diminue la performance en temps de réponse. Est-ce que c'est vrai ?
2) Est-ce que le fait de changer le type d'EJB en un EJB Entity CMP peut améliorer le temps de réponse ?
3) Est-ce que les EJBs 3.0 sont plus performants et rapides que les EJB 2.0 ? Si oui, comment peut-on migrer d'un EJB 2.0 vers un EJB 3.0.

J'ai d'autres question concernant les procédures stockées postgresql mais je crois que je vais les demander dans le forum postgresql.

Merci d'avance.

Au revoir.

[bmoussaud]

La premiere question à se poser est "Qu'est-ce qui fait que mes temps de réponses sont mauvais ?". Seule un profiling ou un test de performance peut répondre à cette question. Il ne faut pas 'accuser' sans preuves EJB 2.0, Spring MVC,..On est souvent surpris de voir que le temps passés en trop est souvent ailleurs...

Pour revenir à tes questions:
1/Spring MVC avec les EJB 2.0 diminue la performance en temps de réponse?. A priori non! Tu utilises le type d'EJB le plus performant. Coté client, as tu implémenté un cache des Home (Les lookups JNDI coutes tres tres chers!). Voir si Spring ne propose pas ce pattern dans son framework

2/De EJB Sessions Stateless vers un EJB Entity CMP. D'abord ce n'est pas le meme modèle et donc pas la meme utilisation. Le pattern 'classique' est d'exposer un EJB Session Stateless qui va exposer des méthodes (services). L'implementation des services peut se baser (ou non) sur l'utilisation d'EJB entity CMP. Comment as tu implémentés ton acces aux données ? En natif par du JDBC ? un outil de type iBatis ou Hibernate ?...

3/Est-ce que les EJBs 3.0 sont plus performants et rapides que les EJB 2.0 ? Du point de vue de la spécification, ca devrait mais ca reste à prouver.

[ran_hery]

Il y a déjà eu une amélioration. J'ai oublié de fermer les connexions à la base
(Accès aux données pure JDBC) et il a fallu fermer toutes les connexions. Maintenant, le système devient rapide.

[rocel]

cette info m'interesse est ce que tu peux détailler comment tu fermes les connexions à la base? stp

[*alexandre*]

Je peux déjà te dire que Spring c'est super lent, Spring couplé à JSF donne des performances execrables, je pense pas que ca soit différent avec Spring MVC ...

[fr1man]

Je peux déjà te dire que Spring c'est super lent, Spring couplé à JSF donne des performances execrables, je pense pas que ca soit différent avec Spring MVC ...

Lent par rapport à quoi ?
Une subaru, c'est lent ?
Par rapport à une F1 oui, par rapport à une 2CV, non...

[rocel]

c'est sure tout est relatif, mais dans mon application le temps de réponse peut aller jusqu'a 5 secondes ...

[fr1man]

Ou passe-tu le plus de temps ?
Ca peut-être la base de données qui a trop à faire.
Essaie de mettre des "sondes" dans ton code pour voir où tu passe le plus de temps.

[OButterlin]

cette info m'interesse est ce que tu peux détailler comment tu fermes les connexions à la base? stp

Ca dépend un peu de comment tu la prends... pool de connexion ou JDBC.
En JDBC ce serait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Connection connection = null;
try
{
   connection = DriverManager... ou autre
...
}
catch (Throwable t)
{
}
finally
{
   if ( connection != null ) connection.close(); // Tout simplement
}

a+