2012/12/20 Christophe Merlet <[email protected]> > 1355960486.937 0 93.31.155.175 TCP_HIT/200 25368 GET > http://tile.openstreetmap.org/15/16500/11681.png - NONE/- image/png
L'expression régulière ne doit traiter que les URL d'une tuile et pas les URL d'autres pages qui seront ignorées (s'il y en a aussi dans le log). En ignorant le reste de la ligne sur les statuts (si on ne veut que mesurer la charge du serveur) il n'y a que 4 champs à prendre par ligne avec une unique expression régulière par ligne. Pas besoin de base, un script PHP peut lire plusieurs milliions de lignes comme ça en moins de 2 secondes pour obtenir le quadruplet: (1355960486.937, 15, 16500, 11681) Autrement dit le timestamp en secondes qui sert juste à déterminer l'intervalle de date pour le calcul de moyenne, et les numéros de tuile pour chaque niveau de zoom. On peut ignorer l'adresse IP du client (ici 93.31.155.175 : c'est une donnée PRIVÉE, à ne pas publier elle gélolocalise le client et peut l'identifier précisément avec le timestamp...), et le protocole utilisé (TCP), le statut du cache (HIT) et de la réponse (200). A priori on peut ignorer aussi le verbe de requête (GET) et le MediaType retourné (image/png) même si la réponse du serveur a été une erreur (requête invalide). Cela dépend des autres requêtes qui passent par ce même proxy et présentes aussi dans le même log. Cependant si le serveur a une erreur 5xx, cela peut signifier son anomalie temporaire, et on peut marquer le timestamp où ça se produit et celui où ça s'arrête pour soustraire ce temps de l'intervalle de temps (qui sert à calculer la moyenne horaire des hits). Si l'ntervalle de temps n'a aucune période sans erreur 5xx, le serveur a un problème et on peut retourner une couleur par défaut distincte (gris par exemple au lieu d'un dégradé du blanc au rouge). Sinon on traite cette ligne dans les cumuls : Il n'y a plus qu'à retourner pour un niveau donné (pour une "tuile") l'image correspondant au nombre de tuiles dans un "bucket" formé par le numéro de tuile demandé et autour (si on demande la tuile statistique au niveau "n" en "x", "y", on peut cumuler le nombre de hits trouvés sur: - (x-16..x+15) et y +/- 14 pour le niveau n+4 - (x-8..x+7) et y +/- 7 pour le niveau n+3 - (x-4..x+3) et y +/- 3 pour le niveau n+2 ... (recoller les largeurs d'intervalles x/y en fonction du découpage des tuiles entre un niveau de zoom n et le niveau n+1, pour qu'elles occupent la même surface réelle, si ce n'est pas comme ici une division du niveau N en 4 tuiles du niveau N+1). Pour les valeurs x +/- i faire le calcul modulo l'intervalle couvrant les 360° de longitude, pour les y (latitudes) borner avec un min/max sur l'intervalle couvrant les 180° de latitude. On ignore toutes les lignes qui sortent de ces cadres et celles sortant de l'intervalle de timestamp, on divise par la durée de l'intervalle de recherche. Si on veut, on peut cumuler non pas les hits mais la taille en octets des requêtes (qui est aussi dans chaque ligne, ici 25368 octets). Le tout se fait en cumulant dans un unique entier pour parser tout le fichier log. Aucune base de données nécessaire, il faut juste pouvoir accéder au fichier log pour le lire. Ceci fait on a un seul nombre qu'on normalise dans un intervalle de 0 à 100 pour retourner une image statique selon la note obtenue. 2 pages de code PHP suffiront largement pour ça. Autour on met une autre page PHP statique pour déclarer la ressource WMS et c'est tout. Il reste à créer le dossier contenant les 100 images de tuiles (on peut aussi générer le PNG par le même script, c'est juste inutilement compliqué à coder quand un nombre fini d'images statiques suffit). Le test à faire ensuite c'est pour les constantes de normalisation (pour éviter d'avoir une carte toute blanche ou toute rouge), le nombre de sous-tuiles à moyenner autour d'une coordonnée zoom/x/y, et pour régler la longueur de l'intervalle de temps (à voir avec un log complet sur le cas pratique, bien qu'on puisse aussi normaliser en gardant trace de la statistique maximale obtenue sur des logs plus longs).
_______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
