Question

I have a WordPress plugin, which checks for an updated version of itself every hour with my website. On my website, I have a script running which listens for such update requests and responds with data.

What I want to implement is some basic analytics for this script, which can give me information like no of requests per day, no of unique requests per day/week/month etc.

What is the best way to go about this?

1. Use some existing analytics script which can do the job for me
2. Log this information in a file on the server and process that file on my computer to get the information out
3. Log this information in a database on the server and use queries to fetch the information

Also there will be about 4000 to 5000 requests every hour, so whatever approach I take should not be too heavy on the server.

I know this is a very open ended question, but I couldn’t find anything useful that can get me started in a particular direction.

Answer 1

Wow. I’m surprised this doesn’t have any answers yet. Anyways, here goes:

1. Using an existing script / framework

Obviously, Google analytics won’t work for you since it is javascript based. I’m sure there exists PHP analytical frameworks out there. Whether you use them or not is really a matter of your personal choice. Do these existing frameworks record everything you need? If not, do they lend themselves to be easily modified? You could use a good existing framework and choose not to reinvent the wheel. Personally, I would write my own just for the learning experience.

I don’t know any such frameworks off the top of my head because I’ve never needed one. I could do a Google search and paste the first few results here, but then so could you.

2. Log in a file or MySQL

There is absolutely NO GOOD REASON to log to a file. You’d first log it to a file. Then write a script to parse this file.Tomorrow you decide you want to capture some additional information. You now need to modify your parsing script. This will get messy. What I’m getting at is – you do not need to use a file as an intermediate store before the database. 4-5k write requests an hour (I don’t think there will be a lot of read requests apart from when you query the DB) is a breeze for MySQL. Furthermore, since this DB won’t be used to serve up data to users, you don’t care if it is slightly un-optimized. As I see it, you’re the only one who’ll be querying the database.

EDIT:
When you talked about using a file, I assumed you meant to use it as a temporary store only until you process the file and transfer the contents to a DB. If you did not mean that, and instead meant to store the information permanently in files – that would be a nightmare. Imagine trying to query for certain information that is scattered across files. Not only would you have to write a script that can parse the files, you’d have to right a non-trivial script that can query them without loading all the contents into memory. That would get nasty very, very fast and tremendously impair your abilities to spot trends in data etc.

Once again – 4-5K might seem like a lot of requests, but a well optimized DB can handle it. Querying a reasonably optimized DB will be magnitudes upon magnitudes of orders faster than parsing and querying numerous files.