Je veux écrire un script de compteur Hit pour garder une trace des hits sur des images sur un site Web et les IP d'origine. Les impressions sont supérieures à des centaines de milliers par jour, de sorte que les compteurs seront incrémentés plusieurs fois par seconde.
Je recherche une méthode simple et auto-hébergée (PHP, scripts Python, etc.). Je pensais utiliser MySQL pour garder une trace de cela, mais je devine qu'il y a une voie plus efficace. Quelles sont les bonnes méthodes de maintien des comptoirs?
9 Réponses :
Eh bien, si vous allez utiliser la route PHP, vous pouvez utiliser un SQLite < / a> base de données, mais MySQL est une façon parfaitement raisonnable de stocker cette information et généralement (au moins à partir de ceux que j'ai vus) est de savoir comment cela se fait.
Si vous ne vouliez pas stocker l'adresse IP et aucune autre information, un numéro simple dans un
Le fichier texte pourrait fonctionner.
Je suis un grand fan de SQLite et de fichiers texte simples, mais les deux ne conviennent pas à cette tâche. Supposons plus d'un serveur, plus d'une image, plus d'un hit concurrent, etc ...
Un sujet fascinant. Incrémentation d'un compteur, simple comme il se peut que, juste a est une transaction ... signification, il peut verrouiller tout le DB pendant plus longtemps que de sens! -) Il peut facilement être le goulot d'étranglement pour tout le système.
Si vous avez besoin de comptes rigoureusement exacts, mais n'en avez pas besoin d'être instantanément à jour, mon approche préférée consiste à ajouter les informations dénombrables à un journal (des journaux de commutation aussi souvent que nécessaire pour la fraîcheur des données). Une fois qu'un journal est fermé (avec des milliers d'événements comptables), un script peut le lire et mettre à jour tout ce qui est nécessaire dans une seule transaction - peut-être pas intuitif, mais beaucoup plus rapide que des milliers de serrures simples.
Ensuite, il y a des compteurs extrêmement rapides qui ne sont que statistiquement précis - mais depuis que vous ne dites pas que cette imprécision est acceptable, je ne vais pas les expliquer plus en profondeur.
La plupart des serveurs Websser fournissent de toute façon ce journal. Voir ma réponse.
@Middus, bien sûr, mais mon point est que (même si ce que vous vous souciez de ne pas être enregistré, ou vous êtes sur un hôte qui ne vous donne pas accès à des journaux), vous pouvez toujours compter via des journaux dédiés de votre propre (il Peut également être beaucoup plus rapide de traiter de tels journaux que ceux généraux, comme vous pouvez les adapter à des besoins en comptant; vous pouvez mettre à jour le DB raisonnablement souvent en fermant les journaux de comptage beaucoup plus souvent que ceux généraux; etc.).
Oui, bien sûr que tu as raison. Toutefois, dans ce cas particulier, lorsque vous avez affaire à des images, vous devez piloter tout le trafic via un script de quelque sorte, ce qui est une frontière assez importante. (Au moins je ne peux pas voir une meilleure option).
@Middus, de meilleures options pourraient inclure en veillant à ce que les images soient desservies par un processus de serveur séparé (non difficile, en organisant des répertoires de manière appropriée - ils doivent normalement être servis sur un domaine distinct de toute façon pour éviter les frais de cookie inutile. ) et configurez la journalisation d'un serveur séparé à cet effet. Mais cela comprenne plus d'un Serverfault Subththead ;-).
Il y a deux manières très faciles:
L'option 1 fonctionne avec des outils hors tension. L'option 2 ne nécessite qu'un peu de programmation, mais vous donne quelque chose de plus proche des mises à jour en temps réel sans vous faire tomber lorsque les pointes de la circulation (telles que vous trouverez dans votre cas MySQL direct).
Je ne sais pas si c'est votre allée, mais appengine est une très belle plate-forme à construire sur. Certains échantillons de code que vous pouvez utiliser pour créer un compteur à l'aide de leur magasin de données et des transactions sont décrits ici: http://code.google.com/appengine/docs/python/datastore/transactions.html .
Nous avons essayé de stocker de nombreux compteurs dans App Moteur et nous devons être coûteux en temps processeur. C'est-à-dire que cela coûte $$.
Si la précision est importante, vous pouvez le faire légèrement plus lentement avec MySQL ... Créez une table de tas / mémoire pour stocker vos valeurs de compteur. Ces tables en mémoire rapides flammes. Vous pouvez écrire les données dans une table normale à intervalles.
Basé sur les idées de moteur App, vous pouvez utiliser MemCache comme un magasin temporaire pour votre comptoir. L'incrémentation d'un compteur MEMCACHE est plus rapide que d'utiliser les tables de démarrage MySQL (je pense). Une fois toutes les cinq ou dix secondes, vous pouvez lire le compteur Memcache et écrire ce numéro dans votre DB.
Vous pouvez prendre le journal d'accès de votre serveur Web (Apache: Access.log) et l'évaluer l'heure et l'autre (Cronjob) au cas où vous n'avez pas besoin de disposer des données à la main exactement de temps quand quelqu'un visite votre site.
Habituellement, l'Access.Log est généré de toute façon et contient la ressource demandée ainsi que le temps, la date et l'adresse IP de l'utilisateur. De cette façon, vous n'avez pas à acheminer tous les trafics via un script PHP. Machine de comptage maigre, moyenne de comptage.
Vous pouvez utiliser Redis - C'est un stockage de valeur de clé très rapide avec support pour incréments atomiques. Si besoin survient - compte les données pourraient être écartées entre plusieurs serveurs facilement.
J'ai fait quelque chose de très similaire, sur une échelle similaire (plusieurs serveurs, des centaines de domaines, plusieurs milliers de hits par heure) et l'analyse des fichiers journaux était définitivement la voie à suivre. (Il a également vérifié les taux de frappe, les pondé par type de fichier et les adresses IP sur la liste noire au pare-feu s'ils produisaient trop de demandes; son objectif était de bloquer automatiquement les bottes, ne pas être un comptoir, mais le comptage était un pièce essentielle de celui-ci.)
aucun impact sur la performance sur le processus de serveur Web lui-même, car cela ne fait aucun travail supplémentaire là-bas, et vous pourriez facilement publier des chiffres de frappe périodiquement mis à jour en les injectant dans la base de données du site toutes les minutes / 5 minutes / 100 hits / Peu importe Devoir verrouiller la ligne / une base de données / base de données pertinente (en fonction du mécanisme de verrouillage utilisé) sur chaque coup.
Cela semble génial, des conseils sur la façon de commencer à créer cela? Peut-il être fait avec php?
@ SWT83: J'ai utilisé Perl, mais je crois comprendre que PHP a été étendu à fonctionner dans des environnements non-web, il devrait donc être possible. Pour un comptoir simple, il s'agit essentiellement d'une question de mise en place d'un travail cron à courir de temps en temps, vérifiez l'accès à de nouvelles hits (enregistrez la position finale de fichier à chaque fois pour que la prochaine exécution puisse ramasser de la suivante. Le dernier a laissé au lieu de ré-traiter tout le journal), et processus / résumez-les comme vous le souhaitez. Si vous le souhaitez en temps réel, écrivez-le sous la forme d'un moniteur de type queue -f à partir du fichier tel qu'il est écrit (faites attention à la rotation du journal).
Sans aucun doute, Redis est parfait pour ce problème. Cela nécessite environ une minute pour la configuration et l'installation, prend en charge les incréments atomiques, est incroyablement rapide, contient des libs client pour Python et PHP (et de nombreuses autres langues), est durable (instantanés, journal, réplication).
stocker chaque compteur à sa propre clé. Ensuite, simplement