Discussion :

[artiom]

Bonjour a tous,

Je voudrais mettre en place un système décisionnel pour le cache (en général) de mon appli web.

Le principe serait super simple: Je regarde la fréquence des connexions d'un utilisateur et en fonction de cela je détermine si je rends le cache persistant pour cet utilisateur ou pas.

Bon dit comme ca, le principe parait évident, cependant l'idée serait d'utiliser un classificateur bayésien pour la partie décisionnelle, et de baser la décision sur plein d'autres paramètres (classes) comme la période de l'année, la durée de la connection, le temps moyen d'affichage pour cet utilisateur, le type d'actions effectués, nbr de requettes par page et ou par connexion, la taille totale du cache de l'utilisateur, etc.

cela permettrait de déterminer de manière intelligente et dynamique quels utilisateurs doivent avoir un cache maintenu (persistant) entre deux connections.

Pour info je ne peux, pour des raisons de ressources et autres, rendre ce cache persistant pour tous les users.

Savez vous si de tels outils existent? si oui, quels seraient les mots clés adéquates pour faire mes petites recherches?

Merci =)

[doc malkovich]

Google Analytics ?
Ce n'est pas géré via le serveur d'applis ?

Sinon le mieux serait de stocker les données dans une petite base avec 1 table ou 2, et de passer un coup de datamining dessus.
Tu as pour ça le langage R ou des outils comme rapidminer qui ont des algos prêts à l'emploi.
Ici c'est plus le côté BI / modélisation en étoile pour permettre à un utilisateur lambda d'être autonome en reporting ou analyse (résumé express de la BI ), on ne pourra pas trop t'aider là-dessus désolé
Il faut t'adresser aux pros du datamining, je te redirige

[Jester]

Etape 1 : logger des données d'utilisation.

Etape 2 : faire une étude sur l'impact de caché pas caché. prendre une règle heuristique par exemple (si tel service et tel domaine toujours en cache).

Etape 3 : faire un modèle bayésien ou autre à partir des logs d'utilisation (étape 1). Par exemple le faire tourner 1x par semaine. Il produit un profil de mise en cache (infrastructure de cache sélectif réalisée à l'étape 2).

Le mieux serait de le coder comme l'appli web, avec un cron qui lance l'apprentissage 1x par semaine en période creuse. D'expérience, la partie modèle pur n'est pas la plus coûteuse en dev mais bien toute l'infra autour.

[artiom]

Merci pour toutes ces infos, je vais approfondir tout ca!

Au passage le language R c'est vraiment pratique!!! Merci ;-)