EntryInfo cache size....

[Jonghyuk Choi <jongchoi@us.ibm.com>]

>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.

The reason I'm focusing on the caching issue is that the syncrepl engine
accesses entries in a sequential fashion so there's little locality.
Also, the syncrepl access pattern and the client access pattern are
generally independent. In fact, a large sequential access by the syncrepl
engine can make the EntryInfo cache virtually ineffective when the system
is memory constrained, if we can't control the size of EntryInfo cache.

>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.

Yes. they'll definitely help to improve performance but I suspect they are major factors
especially when a session is very long as in Stanford's case.

- Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979