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 >
>
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
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
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
> 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
>
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
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
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
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
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
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
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
**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
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
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
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
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
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
18 matches
Mail list logo
