Right now, it's logging the client's IP, the page that they're viewing, the page that they came from, the time of the visit, and their system and browser info. I think I'm going to go with a database to store the information, but do a mixture of long term and short term storage. I think I'll add an admin command that causes it to go through and generate statistics from the unprocessed data that's been collected, then move that data to a flat, compressed file for archiving purposes and just store the summary information. Ideally, processing of the raw data would only be performed as needed (and infrequently), so the majority of the database interaction would be inserts.
Wow, that was a mouth full. I'd like to have the counter on each page of my site, and (hopefully) it will be getting quite a few hits. I still think the database will probably be the best way to go though as it keeps me from having to even think about file locking issues. ---Matt -----Original Message----- From: Justin French [mailto:[EMAIL PROTECTED] Sent: Sunday, February 23, 2003 5:12 PM To: Matt Honeycutt; Php-General Subject: Re: [PHP] Another Logging Question on 24/02/03 3:30 AM, Matt Honeycutt ([EMAIL PROTECTED]) wrote: > I'd like for my counter/logger to be fairly scalable, so I'm toying with two > possible implementation routes: what are you logging (what kind of data) > 1. Have the counter dump visitor info to a text file, then run a cron job on > that nightly to process the data and perform a full analysis. Archiving a report, rather than archiving the raw data can save lots of space, and yes a cron would be the best way. the downside is that the report is the ONLY record of the data. > 2. Have the counter dump the visitor info into a DB (probably MySQL), then > process the data whenever the administrator wants to view his stats. On-demand stats will use up more space long-term than generating monthly reports or something... but there are obvious benefits. The biggest issue IMHO is that if your site is processing a large amount of data, processing it over and over and over on demand is going to burden the server. > Anyone have any suggestions or considerations on which method would work > better? Is there something else I should do instead? If you're going to be dealing with large amounts of data, a combination. Perhaps perform a monthly analysis and consolidation of data to keep on demand / real time processing to the current month only... However, make sure you keep the long-term data SOMEWHERE, in case you want to change the reporting, method, or analyse the data a different way. If we're only talking about a counter on a few pages, real-time should be fine. Justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
