Ne pourrais-tu pas Pieren, ajouter dans une prochaine release, et avec accord de l'utilisateur, remonter les opérations par un webservice afin d'alimenter un compteur ?
ça permettrait d'avoir : - le nombre d'utilisateur - le nombre d'utilisateur par jour/semaine/mois - le nombre de requête vers le serveur - le nombre de requête par jour/sem/mois - le nombre de requête moyen par utilisateur - le nombre de requête par commune ... On peut faire ça par webservice ou syslog. Si syslog, il faudra alimenter une base rrd pour grapher des données utiles, si webservice, ça permet de sotcker des données comme on veut et pour les utiliser, on peut grapher comme on veut, soit présenter les données pour rrdtool, soit utiliser groovy et présenter ça dans un gwt timeline, ou uniquement affichier les compteurs dans une simple page web ce qui est une solution simple et rapide à mettre en place. Maintenant est-ce que c'est pertinent... Je pense que ça peut l'être, pour voir si ça vaut le coup de faire un proxy-cache devant le serveur wms de la DGFIP. 2009/12/18 Pieren <pier...@gmail.com> > 2009/12/16 OSM Léon <osm.l...@gmail.com>: > > Quelqu'un sait ce qui cause un tel encombrement du serveur ? Depuis > quelques > > jours impossible d'utiliser le cadastre hors de la nuit pour ma part. > > > > Pour donner une idée du succès du cadastre en ligne, et d'après cet > article ([1]) paru en septembre 2009 mais tiré d'une conférence faite > en décembre 2008, > "le site a enregistré 8,4 millions de visites pour près de 95 millions > de pages consultées et 4,6 millions d’extraits de plans ont été > téléchargés". > > Comme il est ouvert depuis début 2008, ces chiffres couvrent une > période de 12 à 18 mois, ce qui donne une idée du trafic supporté par > les serveurs. Le plugin n'utilisant pas la fonction d'extraits de > plans (ceux qui s'exportent au format PDF), on peut considérer qu'il > faut partie des 95 millions de pages visitées. > Comme j'estime qu'à vue de nez, on doit être tout au plus une petite > vintaine à utiliser le plugin (peut-être plus mais certainement > beaucoup moins simultanément), ça n'est pas celui-ci qui pose les > problèmes actuels de surcharge ;-) > > Pieren > > [1] http://media.baliz-geospatial.com/fr/article > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB <ste...@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
