[Date Prev][Date Next]
From: Jonghyuk Choi [mailto:firstname.lastname@example.org]
For syncrepl, it is required to prevent caching for some of the internal
operations (search, add, modify).
I added o_nocaching flag to the Operation structure, so the entry can be
deleted at the end of operations.
I'm also wondering whether it would be easy to implement the same for the
EntryInfo, esp. in back-hdb.
If the cacheability of both Entry and EntryInfo can be controllable, the
syncrepl operation can be very lightweight.
Given how much back-hdb depends on EntryInfo caching, I think it would cost
more to delete and recreate these nodes than to just keep them around. Keep
in mind that you have to delete them bottom-up, but you're using them
top-down. It would be quite messy. As a speed vs space issue, keeping them is
a big win. In fact I'm about to add code to keep "deleted" EntryInfo's on a
free list, since they are needed so often.
I'm about to do some profiling on the syncrepl stuff; it appears there are
still a lot of unnecessary strdup's and such in the code. Killing those will
help ease the load. There's some basic config parameters (e.g. filter) that
are created and destroyed on the fly that can easily be created a single time
(during configuration) which will help a bit as well.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support