Thanks for the helpful advice, Marc. I toyed with my settings a bit (especially the memory ones -- upping shared_buffers, work_mem and effective_cache_size) to be in line with the suggestions in Christophe Pettus' talk <http://thebuild.com/presentations/not-your-job.pdf>, but did not observe a significant change in the speed of test my suite. Assuming I haven't really screwed up the configuration, my guess would be that changing the settings had minimal effect on test speed is because my test suite never shovels a significant amount of data towards postgres.
Haven't had a chance to try and throw everything into RAM disk but that sounds pretty cool. Your final suggestion about only running a subset of tests rings true with me: Personally, I tend not to worry too much about my overall test suite's > speed, so long as I can run the tests for the section I'm working on well I > then rely on the CI to deliver my final answers > I feel the same way and constantly target particular subsets of my tests, but it's always tempting to see if everything can run a little quicker! Thanks again for the response and advice. - David On Monday, May 4, 2015 at 11:45:55 AM UTC-7, Marc Tamlyn wrote: > > One of the main questions is to work out what is slow. You can often gain > a lot by using the new --keep-db option which maintains the test database > between runs meaning you don't have the DDL time each run. > > A brute force approach which can have an impact is to install postgres on > a RAM disk, this does have some significant performance implications. > > If you are running linux or a brew-installed postgres, it's also possible > that your postgres instance is configured poorly for local development. > Christophe Pettus gave a talk a while back (slides[1]) which gives an > overview of some of the common flags you may want to change from their > 1990s defaults. In particular the section on memory may be appropriate. > > The ideal way to avoid this though is simply to not use the database as > much as possible. There are various ways to approach this, from mocking it > out, to unit testing various objects, to building ORM objects without ever > calling .save() on them. There are a number of resources online for this. > > Personally, I tend not to worry too much about my overall test suite's > speed, so long as I can run the tests for the section I'm working on well I > then rely on the CI to deliver my final answers. As a side note, your CI > should always be trying to mimic live as much as possible - even if you > were to use SQLite locally for testing Django cannot guarantee all > behaviour is completely db agnostic, especially when it comes to constraint > checking. > > Marc > > [1] http://thebuild.com/presentations/not-your-job.pdf > > On 4 May 2015 at 18:00, David Muller <[email protected] <javascript:>> > wrote: > >> Hi everybody, >> >> Recently I've begun to use the PostgreSQL specific fields introduced in >> Django 1.8. My codebase actually uses the special fields (HStoreField and >> ArrayField mostly) frequently enough such that I cannot run my test suite >> on an in memory SQLite database -- I have to run on a PostgreSQL instance. >> >> Running my tests on PostgreSQL is fine, but I miss the zippy performance >> of an in memory SQLite database. If, say, my test code *cannot *be >> refactored itself, what would be your suggested route for test speed >> improvement? I see this outstanding django ticket for UNLOGGED postgres >> tables <https://code.djangoproject.com/ticket/24306>, and also some work >> by aaugustin towards adding a `--parallel` option to the django tests >> <https://github.com/django/django/pull/4063>. Another thought I had >> would be creating "dumb" versions of the PostgreSQL fields that worked in >> SQLite. >> >> I realize, of course, that by using `django.contrib.postgres`, I should >> expect to sacrifice Django's "plug and play database backends" -- still >> curious as to your thoughts of improving test speed for projects that use >> postgres specific fields. >> >> Thanks! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/32aa98c9-a05f-456f-bd0e-96d324104448%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/32aa98c9-a05f-456f-bd0e-96d324104448%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a4d81e44-4f3d-44a4-831b-813e30d6a24a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
