[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST



=20
It looks that I sent an email that was unreadable. Sorry for that.

I recap the content:

The traffic model we are testing contains search and modify operations. =
The search response contains usually a single entry about 3KB in LDIF =
format. There is only a reduce number of LDAP clients (usually one or =
two), that are using async LDAP API and sending a lot of operations per =
second (> 1000 TPS per client). The client side is an OS Delta box.

Under these conditions we have tested that increasing the sending buffer =
of the server has improved the performance. That's the reason I am =
proposing this feature request.

Pierangelo's proposal allowing hard-set the buffer sizes looks ok.

Regards,

Evaristo

----- Mensaje reenviado ----
De: Pierangelo Masarati <masarati@aero.polimi.it>
Para: evaristojosec@yahoo.es
CC: openldap-its@openldap.org
Enviado: martes, 4 de agosto, 2009 9:54:19
Asunto: Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST

Your message was unreadable, you should use text form for messages sent =
to the ITS.

In any case, according to many sources, the default values for TCP =
buffers can be pretty small.  Usually, they can be configured =
system-wide at the OS level (see tcp(7)), or even auto-tuned.

Personally, I have no objections in optionally allowing to hard-set the =
buffer sizes to values one considers appropriate for the intended use of =
slapd.  Since the optimal size roughly depends on latency and bandwidth, =
this may probably need to be configured on a per-listener basis, =
actually.

However, in deployments where this problem becomes critical, usually =
hardware dedicated to slapd is used, so system-wide tuning (and =
auto-tuning) would be the preferred option anyway.  Manual setting =
should be used only when system-wide or auto-tuning is not available or =
accessible for some reason.

p.



     =20