Alex Karasulu is on his way to the Caribbean for a well-deserved
vacation...  Meanwhile, he asked me to post this message to the dev lists at
directory and mina:
===========================

The current problem where Directory is exhibiting an upper limit of 25
requests/sec on an individual client connection is due to a 40 msec delay
imposed by Nagle's algorithm (
http://en.wikipedia.org/wiki/Nagle%27s_algorithm).

The server's actual upper limit is currently measured at approximately 1,300
to 1,500 requests/sec requires, which requires multiple connected clients to
reach this limit.

From the Wikipedia entry:

"This algorithm interacts badly with TCP delayed acknowledgements, a feature
introduced into TCP at roughly the same time in the early 1980s, but by a
different group. With both algorithms enabled, applications which do two
successive writes to a TCP connection, followed by a read, experience a
constant delay of up to 500 milliseconds, the "ACK delay". For this reason,
TCP implementations usually provide applications with an interface to
disable the Nagle algorithm."

MINA has a way to disable Nagle's algorithm by configuring the socket option
to TCP_NODELAY.  Perhaps some others can pick up the discussion and carry
on...

--
timothy

[ Post a follow-up to this message ]

Whaouh !!!

Thanks a lot guys ! I gonna test that as soon as possible, and will
keep you informed of the results.

Thanks again !



On 6/19/06, Timothy Bennett <timothy.eugene.bennett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
 wrote:
> Alex Karasulu is on his way to the Caribbean for a well-deserved vacation=
...
>  Meanwhile, he asked me to post this message to the dev lists at director=
y
> and mina:
>  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>
> The current problem where Directory is exhibiting an upper limit of 25
> requests/sec on an individual client connection is due to a 40 msec delay
> imposed by Nagle's algorithm (
> http://en.wikipedia.org/wiki/Nagle%27s_algorithm).
>
> The server's actual upper limit is currently measured at approximately 1,=
300
> to 1,500 requests/sec requires, which requires multiple connected clients=
to
> reach this limit.
>
> From the Wikipedia entry:
>
> "This algorithm interacts badly with TCP delayed acknowledgements, a feat=
ure
> introduced into TCP at roughly the same time in the early 1980s, but by a
> different group. With both algorithms enabled, applications which do two
> successive writes to a TCP connection, followed by a read, experience a
> constant delay of up to 500 milliseconds, the "ACK delay". For this reaso=
n,
> TCP implementations usually provide applications with an interface to
> disable the Nagle algorithm."
>
> MINA has a way to disable Nagle's algorithm by configuring the socket opt=
ion
> to TCP_NODELAY.  Perhaps some others can pick up the discussion and carry
> on...
>
> --
> timothy


--=20
Cordialement,
Emmanuel L=E9charny

[ Post a follow-up to this message ]

--On Monday, June 19, 2006 7:09 PM +0200 Emmanuel Lecharny
<elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Whaouh !!!
>
> Thanks a lot guys ! I gonna test that as soon as possible, and will
> keep you informed of the results.

This is why using a product like slamd for benchmarking LDAP servers is the
way to go.  It uses multiple distributed clients to get an idea of a
servers performance.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

[ Post a follow-up to this message ]

Yeah, may be but then you won't be able to see that a single user with
the Nagle property disabled has a really low throughtput, which was
our problem lately.

FYI, we where able to test the sevrer with multiple concurrent users
too, and we really are going to use Slamd soon. Gimme 48 hours long
days, and every thing will be fine and on schedule 

On 6/19/06, Quanah Gibson-Mount <quanah-FGKo4X94FMn2fBVCVOL8/A@public.gmane.org> wrote:[vbco
l=seagreen]
>
>
> --On Monday, June 19, 2006 7:09 PM +0200 Emmanuel Lecharny
> <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>
> This is why using a product like slamd for benchmarking LDAP servers is t=[/vbcol]
he
> way to go.  It uses multiple distributed clients to get an idea of a
> servers performance.
>
> --Quanah
>
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITS/Shared Application Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>


--=20
Cordialement,
Emmanuel L=E9charny

[ Post a follow-up to this message ]

Yep - disabling nagle is common practice in LDAP servers.
IIRC it's the combination of nagle on the server and
delayed ack on the client that leads to the stalls, and not
all OS combinations on the client/server lead to the syndrome.

Somewhere I have an e-mail from 1996 from Mr. Nagle himself
acknowledging the issue and blessing disabling his rule in LDAP servers ;)

[ Post a follow-up to this message ]

On 6/20/06, David Boreham <david-Q2lcOYGAZuYPnHn3N7+5xA@public.gmane.org> wrote:
>
> Yep - disabling nagle is common practice in LDAP servers.
> IIRC it's the combination of nagle on the server and
> delayed ack on the client that leads to the stalls, and not
> all OS combinations on the client/server lead to the syndrome.


Yep, I found Windows has different mechanism regarding the Nagle's
algorithm.  It performed OK without disabling it.  I need to install a Linux
box.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

[ Post a follow-up to this message ]