The Apache Web server that handles the www.stonehenge.com domain logs its transactions directly to a MySQL database using a mod_perl handler. This is really cool, because I can perform statistical correlations on hits over the past few months, including such complex things as the average CPU time used for a particular URL (to see if some of my dynamic pages need better caching) and the greatest number of referrers to a particular page.
The Apache Web server that handles the www.stonehenge.com domain logs its transactions directly to a MySQL database using a mod_perl handler. This is really cool, because I can perform statistical correlations on hits over the past few months, including such complex things as the average CPU time used for a particular URL (to see if some of my dynamic pages need better caching) and the greatest number of referrers to a particular page.
However, it’s a bit uncool because even for a moderate site like mine, the storage requirement to hold information about each of the hits over time can grow rapidly (about 100 MB per month at the current hit rate).
Every once in a while, my ISP admin would yell at me and tell me to reduce the size of my MySQL usage. So I’d type a few commands to roll out the oldest data into a second temporary table, then mysqldump that table into a flat file, compress the file, and then delete the information from the original table. If I was feeling particularly nice, I’d also perform an OPTIMIZE TABLE as well. The compressed file takes up far less space than the original file (about one-fifteenth or so), so I could safely store the historical data for a lot longer should I ever want to restore it all for a grand archaeological trip.
But there are many steps to this procedure, and because it was performed infrequently, and I wasn’t smart enough to…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
