Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Oct 2006 13:35:26 +0530
From:      Girish Venkatachalam <girishvenkatachalam@gmail.com>
To:        freebsd-questions Questions list <freebsd-questions@freebsd.org>
Subject:   Re: FreeBSD 6.1 max sockets
Message-ID:  <20061020080526.GA23594@lakshmi.susmita.org>
In-Reply-To: <ADA58663-7D29-4D4E-8439-C1521C1DF891@redstarling.com>
References:  <ADA58663-7D29-4D4E-8439-C1521C1DF891@redstarling.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 19, 2006 at 11:24:30PM +0800, ke han wrote:
> I am writing a socket server deamon in C++ on FreeBSD 6.1 (or 6.2 if  
> this matters to your answer).  What this does is accept many sockets  
> and does a little work with each.  Each socket has low traffic but  
> stay connected for long periods.  All these sockets get accepted  
> through one public ip:port (if this matters).
> So my desire is two things:
> 1 - good event handling for knowing which sockets have new data.  I  
> assume kqueue is the way to go here?
> 2 - I need to know what my limits are on max number of sockets.  If  
> my system is a 64-bit install on a server with 8GB RAM, I need to  
> know how many sockets I can handle.  Also, what options do I have to  
> tune this?  socket buffer size?  Any kernel parameters needed to tune?
> 
As Chuck said select(2) is a good choice. That is what I used. kqueue() is more powerful and certainly much better when it comes to handling large number of sockets since kqueue(2) is very efficient when it comes to polling sockets for events.

If you use select, the problem is that if you have say 2000 sockets and only one socket is available for read/write, then select has a stupid algo to figure out. Doesn't scale well.

But kqueue(2) is very good at that sort of thing. Also kqueue() has a built in event mechanism that can be extended for signals and files also.

If the sockets stay connected for long periods you may also want to enable TCP KEEPALIVE flag on the sockets.

I don't think RAM and processor will be the bottleneck for you.

Since in typical scenarios number of concurrent connected sockets don't usually hit such high limits.

They come and go...

HTH.

Best of luck!

regards,
Girish



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061020080526.GA23594>