Re: Making the test suite run faster

Aymeric merged this on Thursday. Big thanks to him! Now it's time to have a competition to build the machine that will run the Django test suite in the fastest time. :-) On Wednesday, September 9, 2015 at 3:06:30 AM UTC-4, Aymeric Augustin wrote: > > Le 8 sept. 2015 à 18:42, Michael Manfre > >

Re: Making the test suite run faster

Le 8 sept. 2015 à 18:42, Michael Manfre a écrit : > > I agree with Shai. The database backend needs to be able to control this > feature. Yes, I'm implementing that. The feature will be opt-in for database backends. -- Aymeric. -- You received this message because you are subscribed to the

Re: Making the test suite run faster

I agree with Shai. The database backend needs to be able to control this feature. Regards, Michael Manfre On Sun, Sep 6, 2015 at 12:48 PM, Shai Berger wrote: > Hi, > > On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote: > > > > This will require ./runtests.py --no-parallel or ./runtest

Re: Making the test suite run faster

Hi, On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote: > > This will require ./runtests.py --no-parallel or ./runtests.py > --parallel-num=1 to run tests under Oracle. I think it’s a good tradeoff > because the defaults should be optimized for occasional contributors. > Can we somehow

Re: Making the test suite run faster

> On 31 août 2015, at 20:59, Aymeric Augustin > wrote: > > Perhaps we could make the --parallel option the default in runtests.py. You’d > have to pass --parallel-num=1 to disable it. This would help occasional > sprinters unfamiliar with the option. They could just run ./runtests.py, melt >

Re: Making the test suite run faster

On 31 août 2015, at 20:41, Tim Graham wrote: > Aymeric, did you envision any changes to Django's CI setup? Glad you asked :-) I have some thoughts but no definitive opinion. > Currently we run 1 Jenkins executor per CPU, so I don't know that adding > parallelization would have any benefit? (We

Re: Making the test suite run faster

Aymeric, did you envision any changes to Django's CI setup? Currently we run 1 Jenkins executor per CPU, so I don't know that adding parallelization would have any benefit? (We are already using all 8 CPUs when we're running 8 concurrent builds from the matrix.) If not, then I wonder how we can

Re: Making the test suite run faster

Hi Tino, 2015-08-31 8:35 GMT+02:00 Tino de Bruijn : > - What happens when two SerializeMixin tests try to lock the same file? > Does one wait for the other (probably not), or is a lockfile exception > raised? > The second one waits for the first one to complete. This happens all the time because

Re: Making the test suite run faster

Hi Aymeric, Really cool that you pushed this further. Out of curiosity I have two questions: - What happens when two SerializeMixin tests try to lock the same file? Does one wait for the other (probably not), or is a lockfile exception raised? - How does this work in combination with the --keepdb

Re: Making the test suite run faster

On 31 août 2015, at 06:12, Andrew Godwin wrote: > I'm on board merging this without Oracle support - if I understand right, it > means we just have to run those non-parallel for now, so we're not losing > anything, right? Right. -- Aymeric. -- You received this message because you are subs

Re: Making the test suite run faster

I'm on board merging this without Oracle support - if I understand right, it means we just have to run those non-parallel for now, so we're not losing anything, right? Andrew On Sun, Aug 30, 2015 at 1:19 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > I polished my

Re: Making the test suite run faster

Hello, I polished my test parallelization patch a bit. I'd like to merge it before 1.9 alpha. I rewrote history heavily to make the changes easier to review: https://github.com/django/django/pull/4761 Eventually I settled for the approach I dismissed in a previous email: run tests in workers, pas

Re: Making the test suite run faster

**tl;dr** I can run the full test suite in 85 seconds on SQLite, a 4.8x speedup. Hello, Since I last wrote about this project, I improved parallelization by: - reworking the IPC to avoid exchanging tracebacks - implementing database duplication for SQLite, PostgreSQL and MySQL The code is stil

Re: Making the test suite run faster

On 7 févr. 2015, at 15:09, Fabio Caritas Barrionuevo da Luz wrote: > Parallel is different than concurrent Of course. I’m concerned with parallelism here because that’s what gives the performance improvement. Of course I have to make concurrency safe. > did you come to look at the package "te

Re: Making the test suite run faster

Parallel is different than concurrent, did you come to look at the package "testtools", I think it implements something similar to what you want to do https://github.com/testing-cabal/testtools/blob/master/testtools/testsuite.py#L38-L198 http://stackoverflow.com/a/17059844/2975300 Em sexta-fei

Re: Making the test suite run faster

On 7 févr. 2015, at 01:02, Russell Keith-Magee wrote: > I've thought about (but never done anything) about this problem in the past - > my thought for this problem was to use multiple test databases, so you have > isolation. Yes this means you need to do more manual setup (createdb > test_data

Re: Making the test suite run faster

On Sat, Feb 7, 2015 at 12:05 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > As the test suite is growing, it’s getting slower. I’ve tried to make it > faster by running tests in parallel. > > The current state of my experiment is here: > https://github.com/django/dj

Re: Making the test suite run faster

Anything to make the test suite faster is a worthwhile effort. The speed up will be even better for those of us with slower dev systems. Getting the speed boost for in memory sqlite is a good start and Django is much more than an ORM. It'll take work to improve the database isolation for the test s

Making the test suite run faster

Hello, As the test suite is growing, it’s getting slower. I’ve tried to make it faster by running tests in parallel. The current state of my experiment is here: https://github.com/django/django/pull/4063 I’m distributing the tests to workers with t