Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attemptlog too big in low bandwidth environment #5324

Open
Aypak opened this issue Oct 7, 2016 · 10 comments
Open

Attemptlog too big in low bandwidth environment #5324

Aypak opened this issue Oct 7, 2016 · 10 comments

Comments

@Aypak
Copy link
Contributor

Aypak commented Oct 7, 2016

Summary

We are operating in very low bandwidth environments in Zambia, syncing is taking a very long time and attemptlog (which we don't need the data for) is the major part of the issue. Is there a way to disable this table syncing or reducing its size? As a hack we were thinking of writing a script to delete this table before the sync, would that work?

System information

  • Operating system: Ubuntu 14.04
  • Version: 0.16.9
  • Browser: Chrome

Real-life consequences

We are forced to use version 12.10 in low bandwidth environments. This means our rural deployments cannot take advantage of the early childhood modules in version 16 which we really would like. So any ways to reduce the data sync load would be greatly appreciated.

@benjaoming
Copy link
Contributor

@Aypak - deleting the table wouldn't work, as it would just cause the application to break.

Do you use the attemptlog data locally?

@Aypak
Copy link
Contributor Author

Aypak commented Oct 14, 2016

Hi @benjaoming , actually we do not use any of the attemptlog data locally. We're only interested in user stats such as login time, exercises completed, and videos watched. Is there anything at all we can do to prevent the attempt log from syncing or at least reduce the amount of data produced in this table? Thousands of rows of data are produced in this table over even a short period of time

@benjaoming
Copy link
Contributor

If you don't use the data, you could flush the tables regularly? But won't the students need it for their local use?

@Aypak
Copy link
Contributor Author

Aypak commented Oct 14, 2016

I'm not sure if the students need it. What are the consequences of flushing the tables? What functionality will this affect?

@benjaoming
Copy link
Contributor

As I see it, all of the synced models are the same models that store individual user progress locally. So for instance, if we flush them, students won't be able to tell which videos and exercises their user account has completed.

I think the only way to solve this would be to implement a setting that can skip named models.

@benjaoming
Copy link
Contributor

You could possibly look at add_syncing_models in kalite.packages.bundled.securesync.utils in order to introduce a setting that skips certain models.

@Aypak
Copy link
Contributor Author

Aypak commented Dec 27, 2016

Thanks for your response @benjaoming . I'll look into that and see what I come up with. I actually came up with a hacky solution in which i wrote a script that dumps attemptlog into a dummy table before syncing then restores it after. Introducing a setting to skip it is definitely cleaner.
Feliz navidad!

@benjaoming
Copy link
Contributor

@Aypak - sounds like a good way to patch it! :)

But please feel free to introduce a setting that configures behavior differently, in case it doesn't affect default configurations, we should be safe to merge it.

@benjaoming
Copy link
Contributor

I found in the following occurrence an indication that we may rely on AttemptLog to store the fact that a user has completed an exercise in AttemptLog.complete. However, this may also be stored in ExerciseLog.complete, so it seems be fixable.

The code in question is in kalite/distributed/static/js/distributed/exercises/views.js, l:777:

        // if the previous attempt was not yet complete, load it up again as the current attempt log model
        if (this.attempt_collection.length > 0 && !this.attempt_collection.at(0).get("completed")) {
            this.current_attempt_log = this.attempt_collection.at(0);
        }

@benjaoming
Copy link
Contributor

AttemptLog has been removed from the coach report summary as of #5435

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants