1217630 - Python tests taking twice as long to run after bug 1207648

Status: RESOLVED DUPLICATE of bug 1193836

(Tree Management :: Treeherder, defect, P1)

Description

[Ed Morley [:emorley]]

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.

Comment 1

[Ed Morley [:emorley]]

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?

Comment 2

[Mauro Doglio [: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.

Comment 3

[Ed Morley [:emorley]]

Fixed by bug 1193836.