Question

I was thinking to build a system for keeping visitor statistics for seperate web pages located in different domains. Probably the pages will be served as cached due to performance concerns although it’s created with php and has mysql/isam database.

I’m thinking to include a jquery code for all pages. here is the pseudo-code:

function(request, response) 
{
                $.ajax({ url: "http://www.mywebstats.com/post>",
                data: { page: <? echo $current_url; ?>, ip: <? echo $user_ip; ?>, session: <? echo $user_session; ?> },
                dataType: "json",
                type: "POST",
                success: function(data){
                    response(data);
}

And a similar but reversed function for showing visits for those web pages.

I think, i explained what i want to do. The questions are:

1- Is performance gain worth for that kind of approach ?
2- What kind of db storage engine should i use ?

Answer 1

Suppose you were zany and Google analytics wasn’t fitting your needs –

You could build a simple API for http://www.mywebstats.com and run a cron every 5 minutes to push to a receiving script. That way you’re not making a call on the fly every page load.

Your local script would do exactly what you’re doing above except not to an external location. Your local script dumps the user data into a queue, which could be grouped by a token, session info or whatever data to track their browsing path, behavior, whatever. When the cron is called it fetches the last 100 records and sends it to your API.

This should make sense to anyone that’s used cron before.

As for data storage. It depends on how you’re going to interact with the data. Myisam sounds like it would serve your needs fine. InnoDB would simply be choice for you at this point. If you’re using some kind of ORM to retrieve records then you may need to go this route. Myisam for full text match against should you feel the need to run manual search queries on your stats. Kind of depends on what you plan on doing.
Even if you were making the data public and potentially faced reporting millions of records on call, you can still optimize output to be compiled upon receipt where the users are fed a cached report for simplicity and ease on processing.

In short – gather the data locally and use a cron to push it to your stats site. Myisam is fine for what this looks like. My opinion that is.

UPDATE

As for your question – Google Analytics has an API that you can use to fetch data:
http://code.google.com/apis/analytics/docs/gdata/home.html

I have never interacted with it but most likely it has what you might be looking for.

As for separate DB interaction – Not necessarily. You could have one DB for any number of sites, but that wouldn’t make a great deal of sense. I mention what looks like 2 separate DB because your question looks like you’re calling a separate site that is intended to do only 2 things – record stat data and serve stat data. For that purpose, I would definitely say you should have this separated into 2 databases. Especially if there is more than one site calling the API.

Your hit counters can easily be recorded on a cron as well. You would have a separate cron job on your stat site that computes the recently updated pages and updates a simple json string stored in association to the related page. That way your request is light weight. The from there you can either call the counter on the fly if you want to avoid another cron job – OR – you can run an additional cron that fetches the latest page counter results and stores them locally or writes them out to flat text for even further caching.

The thing to remember is the term cron is not intended to be a scary thing. If your host allows you to set them up they are very convenient for basic maintenance and performance improvements… assuming you do them correctly. They still need to be structured in a logical way so you don’t end up writing scripts that run for 5 minutes or time out. But that’s another story. Hopefully you know what you’re doing enough to know what I mean.