Closed
Bug 1217630
Opened 9 years ago
Closed 9 years ago
Python tests taking twice as long to run after bug 1207648
Categories
(Tree Management :: Treeherder, defect, P1)
Tree Management
Treeherder
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1193836
People
(Reporter: emorley, Unassigned)
References
Details
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•9 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)
Comment 2•9 years ago
|
||
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•9 years ago
|
||
Fixed by bug 1193836.
Assignee | ||
Updated•3 years ago
|
Component: Treeherder: Docs & Development → TreeHerder
You need to log in
before you can comment on or make changes to this bug.
Description
•