I agree with both Sergiu and Vincent: - it should use the activity stream - in the future the activity stream should use a queue system to write it's data (the stats system already does that) - the stats should be rewritten to aggregate the activity stream
So I have written an Activity Stream patch to record view events. It works pretty well, except that I have the same issue than with the stats with AJAX calls: http://jira.xwiki.org/jira/browse/XWIKI-4590 It would be really great to have this fixed for 2.2.1. For the activity stream patch I would like to propose it for review for 2.2.1 inclusion too. It's not dangerous as it's behind a setting that is off by default. I'll open a jira task soon. Ludovic Le 22/02/10 09:17, Vincent Massol a écrit : > On Feb 22, 2010, at 8:11 AM, Vincent Massol wrote: > > >> On Feb 21, 2010, at 11:18 PM, Ludovic Dubost wrote: >> >> >>> Hi XWiki devs, >>> >>> We have a project where it is needed to show what users has seen which >>> page, in addition to aggregate statistics. >>> >>> Now there are multiple ways to implement this, namely either using the >>> Activity Stream module (which records page level edit activity) or to use >>> the Statistics module (which records aggregate level view activity). >>> >>> Which of the two systems would be best to use ? >>> >> IMO, in some near future the Stats module will be rewritten to use the >> activity stream module and perform computations to store aggregated data. >> > Some more details. I believe we have only 2 genera choices: > 1) Decide to save raw data and then perform any aggregated computations > (allowing OLAP-based queries, business reporting, data mining) > 2) Decide to perform aggregation in memory and only save a few metrics > > Obviously option 1) is much more powerful and from an architectural POV is > the best. > > For option 1) the main issue is write performance. The solution I have put in > place in the past for this kind of architecture is the following: > * Have the application write to a local queue (JMS queue to be standard) > * Have several physical servers poll the queue and get data from it as fast > as they can and then save the data in a database different from the main > application database. Note that the scalability is perfect since servers get > data from the queue as fast as they can process it but not more and you just > need to add more servers to get better throughput (in addition the servers > don't need to be of the same type). > * Have some separate application querying the raw data database and perform > computations on it and store the result in different tables/database. > > The key point for option 1) is to ensure that the performance or your app is > not impacted at all by the storage of the raw events. > > So we'll need to decide if we want option 1 or 2. > > Thanks > -Vincent > > >> -Vincent >> >> >>> In any case, I would like to implement this as a patch to the standard >>> module with a setting to activate it at a Wiki level. >>> >>> My first choice would be to use the Activity Stream module but I see that >>> we have some code to clean-up the activity stream (is it active ?). I don't >>> think I would want this data to be deleted. >>> >>> WDYT ? >>> >>> Ludovic >>> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
