directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Request Instructions for ApacheDS using Mavibot Partition
Date Sat, 04 Apr 2015 19:12:01 GMT
Le 04/04/15 18:14, Shawn McKinney a écrit :
>
>> On Apr 3, 2015, at 10:04 AM, Shawn McKinney <smckinney@apache.org> wrote:
>>
>> ere are the instructions (so far):
>>
>> 1. Install ADS 1.0.0-M19
>>
>> 2. Import this ldif into the server using studio:
>>
>> http://apaste.info/4Mt 
>>
>> which is the LDIF for configuring a mavibot partition
>>
>> 3. restart the server
>>
>> 4. create the context entry dc=apache,dc=org
>
> Managed to get a mavibot partition running using these instructions.  The only problem
I ran into with the setup was the ldif file from step #2 did not have a blank line trailing
the last entry which caused an error on studio import.  Added a blank line and got past that
problem.
>
> So these instructions are basically good to go and I must say it is very easy to get
mavibot running with apacheds!  I think we should add a page to the apacheds documentation
with these instructions.
>
> I can’t yet tell a difference on search speeds but insert speed has increased ~ 2X.

There should not be a difference on search speed, unless you have a lot
of data and it does not hold into the defined cach with JDBM. What
happens otherwise is that everything is stored in memory in both cases.

But this is not the end of the story. Due to the very problematic
transaction handling in JDBM, we have to hold the reads while a write is
actually done with JDBM, which is a real bugger. In order to do that
(and trying to guarantee some consistency during concurrent read and
writes scenarios) we had to add a hell lot of locks all over the
backend. With Mavibot, those locks will be completely removed, as
Mavibot will have cross-BTrees transactions (ie, you can update many
B-trees and commit them globally), something critical in LDAP
operations. Beside that, reads and write will be totally concurrent, too.

So expect way better performances and consistency with Mavibot, in
scenarios where you have concurrent reads/write, or even when you have
writes occuring.

Regardless, writes will always be faster (and you mention a x2 increase
of performance, something we are currently trying to improve). We expect
to be able to save 50% of the writes we currently do in Mavibot, makibg
it twice faster, by avoiding writing of pages that are modified more
than once.


Mime
View raw message