On Fri, 4 Feb 2005, Denis Banovic wrote: > Hi Leo, > > I have a very similar app running in mod_perl with about 1/2 mio hits a day. > I need to do some optimisation, so I'm just interessted what optimisations > that you are using brought you the best improvements. > Was it preloading modules in the startup.pl or caching the 1x1 gif image, or > maybe optimising the database cache ( I'm using mysql ). > I'm sure you are also having usage peaks, so it would be interessting how > many hits(inserts)/hour can a single server machine handle approx. >
Simplest thing to do is hijack the referer logs, and then parse them at the end. You just need to add a unique ID for each session (via a cookie or in the URL) which is added to the logs [or placed in a standard logged variable] Then write a parser which tracks usage - using referer + page viewed If you don't want to rely on referers then you could encrypt this in the URL... (but watch out for search engines who could hammer your site!!) James > > Thanks > > Denis > > > > > > -----Ursprüngliche Nachricht----- > Von: Leo Lapworth [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 4. Februar 2005 10:37 > An: ben syverson > Cc: modperl@perl.apache.org > Betreff: Re: Logging user's movements > > > H > On 4 Feb 2005, at 08:13, ben syverson wrote: > > > 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? > > > I think the standard approach for user tracking is a 1x1 gif, there are > lots of ways of doing it, here are 2: > > 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 > > > ____________ > Virus checked by G DATA AntiVirusKit > Version: AVK 15.0.2702 from 26.01.2005 > Virus news: www.antiviruslab.com > >
