[Building Sakai] adding user event tracking to sitestats

[Steve Swinsburg]

Hi Paul

If you store in an external db then option 2 would be best. Note that the
Sakai app server is still the one collecting every event then sending it to
the db, so I'd probably try to collect some metrics before and after the
change since there are lots of events being generated when there are many
concurrent users.

It would also be good to look at ways to make sitestats work for when
events are archived out of its tables. Maybe a weekly or monthly
aggregation job so you get live data for the current period and an
aggregated view for older periods.

Cheers
Steve

sent from my mobile device
On 09/05/2014 1:08 AM, "Paul Lukasewych" <plukasew at uwo.ca> wrote:

> Thanks Steve.
>
> We run an external db for sitestats so I'm thinking option 2 would lessen
> the
> load on the primary db and maybe perform better for reads in our case.
>
> Option 1 is also complicated by the fact that we archive our event and
> session
> tables after a period of time. Instructors often want to look for events
> that
> occurred days or even weeks in the past so then we'd have to go looking in
> archive tables as well. However, given enough time running option 2 we'd
> probably have to archive the events there as well.
>
> Paul Lukasewych
> Applications Development Team
> Information Technology Services
> Support Services Building
> Western University
> (519) 661-2111 x80513
> plukasew at uwo.ca
>
> On May 9, 2014 00:45:14 Steve Swinsburg wrote:
> > Hi Paul,
> >
> > Option 1 would be ok if you were able to limit the date ranges and or
> > provide some sort of aggregation for data older than say 24 hours. It's
> > three joins and shouldn't be a lot of work for the database to manage. I
> > know its slow on these particular tables, perhaps a materialised view
> would
> > be good to have here.
> >
> > Option 2 I am wary of because it would need to intercept almost every
> event
> > and do something with it in code. It does do a lot of this now, so the
> > performance tradeoff may be minimal. At least you could leverage the
> event
> > aggregation, though for reading the data you wouldn't be any better off
> > than having a view as in 1.
> >
> > cheers,
> > Steve
> >
> > On Fri, May 9, 2014 at 12:11 AM, Paul Lukasewych <plukasew at uwo.ca>
> wrote:
> > > We would like to add the ability to retrieve the actual event
> information
> > > (not
> > > just an aggregate count) for a particular user from the sitestats tool.
> > > Our
> > > user community is used to having this information available, as it was
> a
> > > standard feature of our previous LMS (WebCT) and was quite heavily
> used.
> > >
> > > >From what I can tell, this could be done in a couple of ways:
> > > 1. On-demand querying of the sakai_event/sakai_session tables (maybe
> there
> > > is
> > > an API call for this instead?) when a user wants to see the event
> details
> > >
> > > 2. Add an extra table to sitestats to store the extended information
> > > rather
> > > than just the count
> > >
> > > >From my experience querying the database directly, option 1 is going
> to
> > > >be
> > >
> > > extremely slow, whereas option 2 is essentially duplicating a lot of
> > > information that already exists elsewhere
> > >
> > > If anyone has done something like this before, or has any
> > > thoughts/opinions
> > > about the best approach, I'd be interested in hearing it.
> > >
> > > Thanks,
> > >
> > > Paul Lukasewych
> > > Applications Development Team
> > > Information Technology Services
> > > Support Services Building
> > > Western University
> > > (519) 661-2111 x80513
> > > plukasew at uwo.ca
> > > _______________________________________________
> > > sakai-dev mailing list
> > > sakai-dev at collab.sakaiproject.org
> > > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> > >
> > > TO UNSUBSCRIBE: send email to
> > > sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> > > "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140509/53206a65/attachment.html