information on -b option to set the backlog limit

[ktechie]

Memcached can be configured using the "-c" option to support certain
number of simultaneous connections. Default is 1024

There is also another option of "-b" to set a backlog queue limit.
These many requests can be kept waiting for connection. Default is
1024

So taking the default values can we say that 1024+1024 requests will
be supported. Out of which 1024 will be served and 1024 will be in
queue. The ones on queue may have slightly more delay.

[Dustin]

On May 22, 10:45 pm, ktechie <kirandoshitec...@gmail.com> wrote:

> There is also another option of "-b" to set a backlog queue limit.
> These many requests can be kept waiting for connection. Default is
> 1024
>
> So taking the default values can we say that 1024+1024 requests will
> be supported. Out of which 1024 will be served and 1024 will be in
> queue. The ones on queue may have slightly more delay.

I'm not sure I'd classify it that way. TCP backlog is how many
incoming connections we tell the kernel to allow to build up between
accept(2) calls. We're answering those as quickly as possible to
accept new connections, but connections and requests are not really
related. Ideally, connections are held open and operations are
executed on existing connections (otherwise, you can easily spend more
time connecting to memcached than having it process a request).

Your application shouldn't ever really be subjected to the TCP backlog
-- it's kind of bad behavior on the part of the server since it leads
to unpredictable delays (vs. a "connection refused" or immediate
hangup). Without a TCP backlog limit of 0, we'd spuriously report
connection refused during connection rushes even when there are few
connections into the server because we can't call accept fast enough.

[ktechie]

Thanks for the reply.

Sorry that I used the connection and request interchangeably.

Let me put the questions as :

If I keep max connection as 2048 and the backlog queue limit as 2048
then how does this differ say in performance from setting
max connection as 3072 and backlog queue limit as 1024.

Now if it is better to keep max connections higher than backlog queue
limit, what is the penalty of keeping the max connections very high.

[Trond Norbye]

On 25. mai 2011, at 08.40, ktechie wrote:

> Thanks for the reply.
>
> Sorry that I used the connection and request interchangeably.
>
> Let me put the questions as :
>
> If I keep max connection as 2048 and the backlog queue limit as 2048
> then how does this differ say in performance from setting
> max connection as 3072 and backlog queue limit as 1024.
>
> Now if it is better to keep max connections higher than backlog queue
> limit, what is the penalty of keeping the max connections very high.
>

It's better to use persistent connections than connecting over and over. Each connection will allocate a fixed number of buffers etc (but the connection object isn't allocated until it is used).

Trond