paged results vs socket send buffer size

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

We are getting some clients which will occationally retrieve ~2.5M data
in one search operation.  If I understand correctly, that can block the
thread running the search operation until the client-side socket accepts
the data.  So I'm wondering what to do, unless I misunderstand the above
completely:

Are paged results reliable now?  Browsing the mailinglists I see a lot
of older problems with them.  Also, what limit is reasonable to use?
I imagine it makes sense to try to keep a page below the socket send
buffer size.

Threads might be safer too, in case many slow clients do this at once.

Regarding the send buffer size, "/sbin/sysctl net.ipv4.tcp_wmem"
currently says the default is 16384 bytes, while tcp_rmem (socket read
buffer size) is 87380 bytes.  How do I pick good defaults for these?  We
care about LDAP read operation speed but not write operation speed, so
maybe it'd make sense to swap these two numbers at least for slapd.

Current stats: Dedicated LDAP server host, Linux x86_64.  Max 8192
connections (ulimit -n 8192), 8G memory.  60-90 new connections and
300-500 requests per second.  1G *.bdb files for 340000 entries in 5
databases.

-- 
Hallvard