Re: [Libevent-users] performance patch

[William Ahern]

On Wed, Feb 27, 2008 at 02:54:41AM +0300, Vsevolod Stakhov wrote:
 Tani Hosokawa ?:
snip
 significant amount of processing to do per request.  The reason I put 
 1024 in there is all implementations that I know of silently truncate 
 the backlog parameter to the system's maximum.  The reason I don't use 
 SOMAXCONN is some OS (older Solaris for sure) are incorrect for backward 
 compatibility reasons, and other OS are incorrect because the actual 
 setting is dynamically tunable via sysctl.
 
snip
 
 As POSIX requires SOMAXCONN to be defined in sys/socket.h it is safe to 
 use this value or define some constant in configure script, that detects 
  SOMAXCONN definition. Also in old Solaris systems backlog was limited 
 to 5.

The problem with SOMAXCONN is the same as FOPEN_MAX (ISO C). The runtime
limit is not the same as the compile-time constant. In fact, usually the
runtime limit is much higher.

On all of my boxes FOPEN_MAX is defined to be 16 or 20. Yet that is
definitely not the runtime limit.

___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Re: [Libevent-users] performance patch

[Niels Provos]

On Tue, Feb 26, 2008 at 12:41 PM, Tani Hosokawa [EMAIL PROTECTED] wrote:
 Under high load, unless you build a dedicated acceptor thread you will
  find that only allowing a listen backlog of 10 connections will cause
  lots of attempted connections to simply be dropped if you have any
  significant amount of processing to do per request.  The reason I put
  1024 in there is all implementations that I know of silently truncate

I just submitted a change to trunk yesterday that raiseed the limit to 128.

I also added a new API, evhttp_accept_socket(), to which you can
provide an already created fd for which you could set the listen queue
to whatever you like.

Niels.
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users