Discussion :

[vieuxblasé]

Bonjour,

Je rencontre des problèmes de performances sur mon application.
La lenteur a été détectée au niveau de la couche de persistance.
Sur mon ancien poste de dev, cela pouvait atteindre 10s pour certains services, souvent 2s.
(Avec un nouveau poste ça va mieux mais cela n'enlève pas le problème...)

J'ai ajouté une propriété dans le persistence.xml pour activer du profiling et voir un peu ce qui se passe.

Ci-dessous, quelques extraits de traces obtenues.
La statistique qui m'étonne est "Timer:ConnectionManagement".
Ce que j'en déduis pour le moment est que le point d'engorgement est l'obtention de la connexion à la base.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
[#|2012-09-25T16:00:00.484+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Profile(DeleteObjectQuery,
    class=com.xxx.yyy.zzz.InvitationBean,
    number of objects=1,
    total time=22802480,
    local time=22802480,
    profiling time=87536,
    Timer:Logging=326600,
    Timer:SqlPrepare=58559,
    Timer:ConnectionManagement=21382287,
    Timer:StatementExecute=903127,
    Timer:DescriptorEvents=10867,
    time/object=22802480,
)
}End profile
|#]
 
[#|2012-09-25T16:06:04.142+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=19;_ThreadName=Thread-2;|Profile(ReadAllQuery,
    class=com.xxx.yyy.zzz.UserBean,
    number of objects=1,
    total time=201965995,
    local time=201965995,
    profiling time=3220715,
    Timer:SqlPrepare=300338,
    Timer:Caching=40448,
    Timer:ConnectionManagement=196344382,
    Timer:Logging=1817727,
    Timer:StatementExecute=1771243,
    Timer:RowFetch=220349,
    Timer:ObjectBuilding=355275,
    Timer:DescriptorEvents=26562,
    time/object=201965995,
)
}End profile
|#]

Côté Glassfish, un pool est défini, configuré par défaut entre 8 et 32 connexions.
La base est Postgresql et la volumétrie des données est ridicule...

J'avoue que je ne sais pas trop quelle piste explorer. Toute suggestion bienvenue.

[slim]

Bonjour,

Il faut commencer par faire du profiling directement sur la base de données.
Sur pgAdmin il y a un onglet qui s'appelle "explain plan" qui permet de mesurer en points la complexité des requetes. Il faut minimiser (au maximum ) le nombre de points => optimisation des requetes

Il faut aussi analyser les index et les requetes envoyées au SGBD. C'est dans la majorité des cas, le problème.

Ensuite, dans l'application :
- au chargement d'une entité : LAZY ou EAGER pour les associations
- dans les algo de traitement faisant appel aux dao : faut-il un batch processing ?

...

[vieuxblasé]

Merci Salim pour ta réponse.

La façon de faire un explain plan avec PG est toujours bonne à savoir.
On va regarder aussi de ce côté-là...

Cependant, comme je disais, la volumétrie des données est minime, le modèle est simple, les requêtes aussi dans l'ensemble.

Mon souci est surtout d'interpréter cette stat "ConnectionManagement".
Si je reprends l'exemple (les autres traces sont similaires) :
total time = 201 965 995 (ns),
Timer:SqlPrepare = 300 338,
Timer:Caching = 40 448,
Timer:ConnectionManagement= 196 344 382,
Timer:StatementExecute = 1 771 243,
etc.

A chaque requête, c'est là que l'essentiel est consommé.

Je cherche donc à comprendre :
- si j'interprète bien en disant que la connexion est trop longue,
- et bien sûr les causes possibles...

[slim]

Si c'est en nano secondes, ça me paraît pas trop long... si ?

là, le "total time" = 0.2 seconde....