* Etude de cas 1: "On demand" vs quotidien

Constat: Tres peu de client admire leur stats web de facon quotidienne. Ainsi generer de telles stats de facon recurante a l'aide, par example, d'un cron job est une perte de ressources.

Solution: Generes les graphs d'access a la demande via un script (CGI ...) lorsqu'un client accede a la "page info" de son domaine.

Pbm: Cette solution n'est certainement pas universelle puisque 1) cela peut creer des problemes de securite (dans le cas perl cgi) mais ceci est tres facilement contournable en auditant son code ou en utilisant d'autres technologies (XML via XSL-Transformations/Java).

La seconde chose a prevoir qui nous vient en tete est: "Que se passe t'il en cas d'augmentation brutale de charge: access concourant lie a la multiplication des vhosts a gerer ? Au regard du "cahier des charges" les logs des differents services doivent etre contenu dans une base SQL -> connexion persistane a la DB pour eviter les 3 way handsake a chaque clicka ?

Neanmoins, quelques soit la technologie utilise il sera necessaire de prevoir une architecture materielle capable de supporter cette charge (a determiner).

Le principal probleme si on souhaite utiliser des images de type SVG (vectorielles) est que tres peu de client disposent d'un navigateur avec le plugin adequat (eg: Adobe SVG Viewer). Il est donc necessaire de tester la presence du plugin a l'aide d'un script js soit de generer a la volee les images PNG a partir des SVG. Nous opterons pour la seconde solution.

* Etude de cas 2: (cf organigramme joint) Choix technologiques.

Permiere constatation, le module Image.SVG de pike ne correspond pas a nos attentes. Il nous faudrait utiliser plusieurs fonctionabilites des modules Image pour arriver a faire ce que nous souhaitons (et encore je n'en suis meme pas sur...)

Le tag <diagram> present dans caudium est une *serieuse* alernative a ce que nous cherchons a mettre en place mais dans la mesure ou nous ne disponsons pas du parc necesaire au deploiment de plusieurs serveurs web et ou le support XML/XSLT de caudium ne devrait pas nous permettre l'utilisation de Cocoon et par suite de Forrest/Lenya nous n'aborderons donc pas cette possibilite.

Neanmoins, pike est un langage puissant, qui beneficie entre autre d'un bon support des bases de donnees. Il devrait donc etre aise de "grapher" les stats depuis les logs present dans notre SGDB.

* Etude de cas 3: Access clients.

L'etude detaille de ce sujet depasse largement les quelques lignes de ce memo.

D'apres nos recherches on peut dire que ceci peut tres bien etre fait a l'aide d'une gestion dynamique des vhost fonde sur une base SQL et une auth egalement SQL (et par suite LDAP dans les deux cas).

eg: stats.nom_de_domaine.com Login: code_client (present dans la base)

Pass: definie en dur dans la base en clair ou crypt/md5

ou a l'aide d'un point de montage genre www.nom_domaine.com/stats

L'access a cette page via une redirection pointe vers /cgi-bin/genstats.cgi?client=$CODE_CLIENT

Une autre idee qui me vient egalement en tete c'est:

https://www.nom_domaine.com/admin ou on peut immaginer regrouper tout ce qui est utile a la gestion de son nom de domaine et les graphs une interpretation XML cote server.

Que se passe t'il si un client a plusieurs non de domaine hoste chez nous. Deux possibilites, le cas classique, deux interfaces sur chaqu'un de ces noms de domaines ou l'agregation des data de ces deux noms de domaines via l'utilisation d'une seule interface. Ceci ne necessite que la modification du template XML de la page specifique a ce client. Une etude detaille afin d'automatise ce proceder sera prevu en cas d'adoption de cette solution. Cela depand essentiellement de la configuration du client: deux sites reelement differents ou deux noms de domaines utilisant le meme DocumentRoot (eg: toto.com & toto.net) ?

Conclusion:

Il existe une multitude de solution repondant au probleme pose. Le fait d'avoir une machine dedie aux logs (log host) etant encore la solution la plus simple et la plus fiable.