[Date Prev][Date Next]
Re: paged results vs socket send buffer size
Michael Ströder wrote:
Hallvard B Furuseth wrote:
Michael Ströder writes:
Is that really a problem? How often is "occasionally"?
Don't know, and don't know.
To me 2.5 MB does not sound so much to justify thinking about changing
the client app in such a network- and data-specific way.
OK, good. I've no experience with that kind of search result sizes
I can only speak of situations where I retrieve the whole directory (up
to 300000 entries) for syncing. But this does not happen very often and
my sync scripts call ldap_result() quite soon and process results as
they come in.
getgrent() with nss_ldap. Others may come later.
Hmm, maybe that's what Volker Lendecke was talking about at LDAPcon 2007
regarding enumeration of groups. See his slides:
Does it block other operations from different apps?
Don't know yet, that's what I was wondering about. Like I said I
imagine it can, if the threads get blocked. We've just multiplied the
server-side sizelimit with 200 to accomodate the change:-(
I guess user-specific limits won't help much.
Right. It would be possible to have slapd internally break up the results to
prevent the thread from getting blocked. There's some question about whether
it's worthwhile to do so (e.g. for a slow client, the time slapd spends
blocked should outweigh the time it takes slapd to requeue the result processing.)
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/