directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Fwd: Speeding up tests
Date Wed, 19 Sep 2007 07:40:16 GMT
Oops, forget to send tis mail _with the content_ to the ML ;)

---------- Forwarded message ----------
From: Emmanuel Lecharny <>
Date: Sep 19, 2007 2:13 AM
Subject: Re: Speeding up tests
To: Alex Karasulu <>

Hi Alex,

some comment in the body :

> Been thinking about this for some time as you know.  At first I just made me
> a ram drive on linux to deal with this :D - it saved like 50% of the time
> but yeah that's laughable (both the technique and the time saved).  But this
> was just a quick remedy.  Still 7 minutes is too long to run integration
> tests.  The bulk of the cost of integration tests comes from bootstrapping
> specifically off the top of my head I'd list the following top time suckers:
>  o partition creation (with various db files)
>      o schema partition
>      o system partition
>  o schema loading and checks
> I suspect you can do thousands of adds, deletes and modifies for the cost of
> bootstrapping.

Exactly. The schema loading is damn costly (more than 600 entries to read)

So my recommendation is to find a way to snapshot the state
> of the server then roll it back with anti-requests.  This really is not as
> complex as it sounds.  We have the capability to do this easily using an
> interceptor much like the changelog interceptor in my embedding workshop
> which Ersin knocked out a while back.  Perhaps for each log operation
> tracked by this interceptor we can have a configuration switch to track the
> anti-ldif.  This would not be too hard to do.
> Add => Delete
> Delete => Add
> Modify (Replace) => Modify (Replace)
> Modify (Remove) => Modify (Add)
> Modify (Add) => Modify (Remove)
> ModifyDn => ModifyDN
> The order would be reversed.  So if you have this train of requests { R1,
> R2, R3, R4, R5 } that correspond to the following LDIF sequence { L1, L2,
> L3, L4, L5 } then you just need the following anti operations { A5, A4, A3.
> A2, A1 }.  Another way to have done this nicely is if we had transactions
> enabled properly.  We could just rolllback :).  But this is a quick
> workaround to the problem.

There is more than that. This bring up some very interesting features :
(1) test speed boost (minimal value)
(2) recording and playback for complex test cases
(3) for snapshoting and rolling back the server to previous states
(4) for creating journals to be used if the server crash

Let's discuss that in a separate thread.

Thanks Alex

> Alex

Emmanuel L├ęcharny

Emmanuel L├ęcharny

View raw message