[Building Sakai] adding user event tracking to sitestats

[Adrian Fish]

Option 2 sounds better to me. Storage is cheap, cpu is expensive, so
spreading the load by picking off the events into a new table, as SS does
now, makes sense.

Cheers,
Adrian.


On 8 May 2014 16:08, 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/20140508/64a2f0ea/attachment.html