Version imprimable
Bon j'ai réussi dans un premier temps à mettre en cache la méthode selestPart !! Youhou !!!!!!!!!!
J'ai reprofilé avec Yourkit et j'ai fait les mêmes tests
Résultats :
Avant : la requete SELECT_QUERY était appelé + de 10000 fois :aie:
Maintenant : elle est appelée 180 fois 8-)
Bon c'est déjà ça de pris.. Maintenant me reste à cacher l'autre et ça va être chocolat..
:ccool: en plus autres effets :
1 - ça va économiser de la mémoire
2 - ça va éviter au Garbage Collector d'avoir à nettoyer ce que le programme consommait puis jetait.
Par contre je constate que le cache se rajoute quelque fois plusieurs fois le même couple clé/valeur alors que je fais bien le test pour voir si le couple existe pas déjà...
J'aimerais mettre en cache maintenant des objets tâches... Le problème c'est avec quelle clé ?
Sachant qu'une tâche est surtout recherchée en fonction de sa date.. Le problème c'est qu'il y a plusieurs tâches pour une date...
Bon j'ai à première vue réussi à mettre en cache la deuxième requête et ça marche.
Par contre, le log de GlassFish me sort cette exception souvent :
Ca semble pas affecter le fonctionnement de l'appli mais j'aimerais bien la faire disparaitre.. Une solution ? merci !Code:
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
Il suffit de regarder cette ligne pour comprendre ce qui est "null" :
beans.EDTBean.constrId(EDTBean.java:515)
Montre ta classe EDTBean et la méthode constrId ...
et niveau perf alors ? y'a du mieux ?
J'ai réussi apparemment à corriger cette exception.
En réalité ça venait du fait que je faisais expirer le cache toutes les 20secondes.
Du coup j'ai l'impression que lorsque l'appli essayait de se connecter au cache au moment où celui ci s'expirait, il accédait à un contenu vide et ça créait cette erreur.. J'ai modifié mes temps d'expiration et là ça roule :ccool:
Et niveau perf, au premier lancement ça met autant de temps (une progressBar), mais après quand on se reconnecte à l'appli ça va carrément plus vite (1/3 de progressBar) :mrgreen:
Maintenant reste à savoir si dans le temps ça va tenir la route.
et oui au premier lancement de tt façon, il n'y a rien à espérer tant que ce n'est pas dans le cache.
bon et bien je suis content que tu aies abouti :ccool:
Mais avant tout merci à toi pour ta précieuse aide :ccool:
Sinon Yourkit m'a bien servi aussi pour ce coup là, il m'a permis de voir les 2 requêtes "principales" qui coutaient le plus de ressources. Du coup en les mettant en cache par effet cascade les autres requêtes qui dépendaient de ces 2 là sont du coup moins appelées :mrgreen:
Bref, un sujet de réglé, maintenant je vais m'attaquer au stockage des requêtes ce qui va être chocolat :aie: