H On 4 Feb 2005, at 08:13, ben syverson wrote:
I think the standard approach for user tracking is a 1x1 gif, there are lots of ways of doing it, here are 2:Hello,
I'm curious how the "pros" would approach an interesting system design problem I'm facing. I'm building a system which keeps track of user's movements through a collection of information (for the sake of argument, a Wiki). For example, if John moves from the "dinosaur" page to the "bird" page, the system logs it -- but only once a day per connection between nodes per user. That is, if Jane then travels from "dinosaur" to "bird," it will log it, but if "John" travels moves back to "dinosaur" from "bird," it won't be logged. The result is a log of every unique connection made by every user that day.
The question is, how would you do this with the least amount of strain on the server?
Javascript + Logs - update tracking when logs are processed
------------------------------------------------------------------------ ---------
Use javascript to set a cookie (session or 24 hours) - if there isn't already one. Then use javascript to do a document write to the gif.
so /tracker/c.gif?c=<user_session_id>&page=dinosaur
It should then be fast (no live processing) and fairly easy to extract this information from the logs and into a db.
Mod_perl - live db updates
-------------------------------------
Alternatively if you need live updates create a mod_perl handle that sits at /tracker/c.gif, processes the parameters and puts them into a database, then returns a gif (I do this, read the gif in and store it as a global when the module starts so it just stays in memory). It's fast and means you can still get the benefits of caching with squid or what ever.
I get about half a million hits a day to my gif.
I think the main point is you should separate it from your main content handler if you want it to be flexible and still allow other levels of caching.
Cheers
Leo
