Python tests taking twice as long to run after bug 1207648

RESOLVED DUPLICATE of bug 1193836

Status

Tree Management
Treeherder: Docs & Development
P1
normal
RESOLVED DUPLICATE of bug 1193836
3 years ago
3 years ago

People

(Reporter: emorley, Unassigned)

Tracking

Details

(Reporter)

Description

3 years ago
Using an arbitrary single test:

vagrant ~/treeherder $ git status
HEAD detached at 818c955
nothing to commit, working directory clean

vagrant ~/treeherder $ time py.test tests/model/test_error_summary.py
...
============================================== 13 passed in 11.78 seconds ==============================================
real    0m13.464s
user    0m7.416s
sys     0m0.676s


Then after updating the repo from the host:

vagrant ~/treeherder $ git status
HEAD detached at 50a879f
nothing to commit, working directory clean

vagrant ~/treeherder $ time py.test tests/model/test_error_summary.py
...
============================================== 13 passed in 21.53 seconds ==============================================
real    0m23.212s
user    0m15.048s
sys     0m0.764s


vagrant ~/treeherder $ rm treeherder/perf/migrations/0002_auto_20151014_0922.py
vagrant ~/treeherder $ time py.test tests/model/test_error_summary.py
...
============================================== 13 passed in 11.81 seconds ==============================================
real    0m13.494s
user    0m7.336s
sys     0m0.752s


-> The migration added by bug 1207648 doubles the Python test runtime both locally and also on Travis. eg compare:
https://travis-ci.org/mozilla/treeherder/builds/85375469
https://travis-ci.org/mozilla/treeherder/builds/85595332

Guessing this is due to the issues with how the test DB is set up, for now I think we could just work around it by squashing the migrations files:
https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations

We'll probably want to wait until we've run the migrate after bug 1216153.
(Reporter)

Comment 1

3 years ago
Hmm so I tried squashing the perf migrations and then deleting the old files as mentioned in the Django migrations docs, however the tests didn't speed up. I notice the squashed migration had a dependency on the 0002_... model migration file, unlike the old perf initial migration, so perhaps it's causing that migration to run anyway?

If I delete all perf and all model migrations and then run a |manage.py makemigrations|, I can get the test runtime back to what it was before.

Mauro, presuming migration has run on all of stage/prod/Heroku/our Vagrant instances, are there any disadvantages to just blowing away the existing migrations and starting from scratch with the initial migration file? I'm presuming the perf difference here is that we're currently using the skip initial migrations option, so get a perf win so long as they are all only initial migrations?
Flags: needinfo?(mdoglio)
You will have to fake-migrate to the initial migration to do that. That will change the content of the django_migrations table and set 0001_initial for the app you want to reset.
Flags: needinfo?(mdoglio)
(Reporter)

Comment 3

3 years ago
Fixed by bug 1193836.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
No longer depends on: 1216153
Resolution: --- → DUPLICATE
Duplicate of bug: 1193836
You need to log in before you can comment on or make changes to this bug.