Le 04/04/15 18:14, Shawn McKinney a écrit : > >> On Apr 3, 2015, at 10:04 AM, Shawn McKinney <[email protected]> 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.
