[stunnel-users] scaling stunnel

Fri Oct 19 00:00:56 CEST 2007

Hi,

I am trying to set up syslog + stunnel in a large environment.  I am
curious about the experience of members of this mailing list regarding
how stunnel + syslog-ng scale.  

I set up a test environment using stunnel 3.26 (because that's what is
in my debian installation)[*].  I configured stunnel to run as a daemon
(starting on boot), and syslog passes off messages and receives messages
from localhost:514.  In the stunnel log, it tells me that there is a
limit of 500 clients, and it seems that with stunnel 3.x, it must be
recompiled to increase this limit.  I found some posts on this list that
say that while stunnel 3.x uses select(), stunnel 4.x uses poll(), which
is much more efficient.  So I figure that if I will have to roll my own
package, I may as well upgrade to 4.x at the same time.  Agree?  If so,
which version?  

It's my understanding that this configuration will create a persistent
connection between the client and server, holding it open until such
time as syslog needs to send a message across it.  How many clients have
you experienced being able to connect to the log aggregator?  My logs
are rather sparse, so I expect I will hit a limit based on processor /
filehandle / memory usage before I start overloading the local disk.
Eventually, I realize that I will have to build a tree structure with
intermediate nodes aggregating logs and passing them on to the central
host, but I would like to know where people have hit that limit.  I
would love to have ~5000 clients connected to each aggregating server.
Is this within the realm of experience?  

Does anybody have tuning suggestions for such high numbers of
connections?  I saw one person mention on the mailing list that
compiling without libwrap allowed him to pass ~2500 connections (though
he didn't give a new ceiling).

Thanks,

-ben

[*] I was actually impressed at how easy this was.  Aside from having to
write my own /etc/init.d/ scripts to start the client and server, I
could bring down either end of the stunnel connection, and things would
just pick up where they left off when the tunnel was reconnected.  Add
monit into the picture and you've got a nice resilient secure logging
system.  Slick!

-- 
Ben Hartshorne
email: ben at hartshorne.net
http://ben.hartshorne.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20071018/6397be5b/attachment.sig>