...
- chaque TGT prenait 'beaucoup' de place, d'une certaine manière celà nous a conforté dans un premier temps aux choix de JPA et donc de la base de données pour la persistence des tickets.
- mais la base de données ne faisait qu'augmenter ... et donc la purge des tickets ne se faisait vraissemblablement pas correctement - cf ce graphe munin de 24 heures d'exploitation en production :
En regardant les logs CAS, on trouve l'erreur récurrente suivante (ceci est un extrait : on n'a conservé que les lignes 'intéressantes') :
...
De même le stockage en ram comme en fichier (fichier de dump) requiert donc finalement peu d'espace. Là où nous avions besoin d'environ 3GB pour 30.000 TGT, c'est 300MB de RAM qu'il nous faut.
Les graphes suivants montrent sur 3 jours l'usage redis en nombre de tickets et RAM utilisée.
A noter que le lundi (15 juillet) on recense environ 15000 visites sur le CAS pour 10000 visiteurs différents et un total de 170000 tickets créés.
On a en fait usuellement 2 fois plus de fréquentation un jour hors période de vacances scolaires.
Rappel également pour donner une ordre de grandeur : notre université accueille environ 30.000 étudiants.
En imaginant que le service soit effectivement utilisé par quelques milliers personnes depuis leurs mobiles (quasimenet 1 visite sur 2 sur notre CAS se fait actuellement depuis un mobile), on peut imaginer que Redis peut avoir des pics de consommation de RAM de 3GB de RAM.
Proposer 14 jours de persistence de TGT sur les mobiles pour les utilisateurs qui choissent l'option 'se souvenir de moi' est Proposer 14 jours de persistence de TGT sur les mobiles pour les utilisateurs qui choissent l'option 'se souvenir de moi' est finalement à portée avec le ticket registry sous Redis.
...