[p2pu-dev] Course metrics

[Dirk Uys]

Hi everyone

I love all the good ideas floating around!

For the time being I changed the metrics to be updated once daily by a
celery task. Only the metrics for running courses are being updated. Iow,
if the course is under development, archived or a test course, metrics
won't be updated.

I think we should keep record of the suggestions we had/have about metrics.
At the moment the proper place seems to be Trello (
https://trello.com/board/project-pipeline/4ec0f020c137ff072a5d8afa) if this
doesn't work, we'll have to figure something out that does.

I think discussions still needs to happen on the mailing lists, but the
Trello cards can be used to keep some notes on the discussion we had.

Now it's on to reply by email!

Cheers
d

On Wed, Jun 20, 2012 at 6:56 PM, Alison Cole <alison at p2pu.org> wrote:

> Hey Dirk, Although all of this is over my head I just want to let you know
> how much I appreciate you posting these problem solving posts. I'm learning
> a lot about programming by reading these and what you do behind the scenes!
> Thanks for all your hard work being a one man show!
>
>
> On Tuesday, June 19, 2012, Dirk Uys wrote:
>
>> Hi everyone
>>
>> During the last release on 18 May I enabled course metrics for all course
>> organizers believing that the metrics were working perfectly and that it's
>> simply a permission update. You know what they say about assumption...
>>
>> The problem is that when a user goes to the metric page for a course the
>> metrics get generated from the recorded page views (
>> https://github.com/p2pu/lernanta/blob/master/lernanta/apps/tracker/models.py#L100).
>> If the user refreshes the page (because it's taking so long), the process
>> is started again and the metric updating procedure happens concurrently.
>> This doesn't play nice with the intended use of the db and duplicated data
>> is generated :(
>>
>> Now, solving this problem has multiple possibilities! Each with pros and
>> cons.
>>
>> 1. Enforce some locking mechanism to ensure the operation only happens
>> once
>> + process doesn't run concurrently
>> - user waits
>> - lots of db work tied to specific requests
>>
>> 2. Queue a celery tasks that runs to operation
>> + user doesn't need to wait for results
>> - still need to implement some locking mechanism to prevent celery tasks
>> from running concurrently
>> - lots of db work tied to specific requests
>>
>> 3. Keep the table updated from the get go
>> + metrics are always up to date
>> - introduces small overhead to every page view
>> - generate metrics that's never used
>>
>> 4. Fix the data duplication issue that presents itself
>> + doesn't matter if process runs concurrently
>> - update still takes a long time
>> - lots of db work tied to specific requests
>>
>> 5. Don't trigger the update process based on user actions, but rather at
>> a predetermined time
>> + user doesn't wait
>> - generate metrics that's never used
>>
>> 6. ?
>>
>> Does anyone have any thoughts on this?
>>
>> Cheers
>> d
>>
>
>
> --
>
> Alison
>
>
> _______________________________________________
> p2pu-dev mailing list
> p2pu-dev at lists.p2pu.org
> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20120621/f43eb840/attachment.html>