I will go with stunnel for now. Thank you all! On Fri, Apr 16, 2010 at 3:06 AM, duncan hall <dun...@viator.com> wrote: > While I agree NGINX will offer much more flexibility (caching, ssl offload > and compression), stunnel can be configured for multiple vhosts: > > I have moved to NGINX but here is a copy of my old stunnel.conf showing 2 > hosts > > cat /etc/stunnel/stunnel.conf > > > pid = /var/run/stunnel.pid > > #debug = 7 > output = /var/log/stunnel.log > > socket=l:TCP_NODELAY=1 > socket=r:TCP_NODELAY=1 > > [https-hotelsite] > cert=/etc/stunnel/hotelsite.crt > key=/etc/stunnel/hotelsite.key > accept=10.20.19.118:443 > connect=10.20.19.118:80 > xforwardedfor=yes > options = NO_SSLv2 > > [https-flightsite] > cert=/etc/stunnel/flightsite.crt > key=/etc/stunnel/flightsite.key > accept=10.20.19.115:443 > connect=10.20.19.115:80 > xforwardedfor=yes > options = NO_SSLv2 > > #OEF > > > Bernhard Krieger wrote: >> >> We changed from stunnel to nginx. >> If you have several Vhosts (Certs ), you need several stunnel instances. >> Now its one instance. >> Additionally nginx has more options to configure.... >> >> regards >> Bernhard >> >> Am 16.04.2010 06:45, schrieb Willy Tarreau: >>> >>> Hi Gabriel, >>> >>> On Thu, Apr 15, 2010 at 11:23:37PM -0300, Gabriel Sosa wrote: >>> >>>> >>>> I'm really happy using haproxy so far (so thank you), we are doing >>>> load balancing of http and smtp with great results >>>> >>>> now we need to be able to LB ssl connections and get the ip of our >>>> customers. >>>> >>> >>> For that you can use the x-forwarded-for patch for stunnel, available on >>> haproxy's site. >>> >>> >>>> >>>> In the official haproxy's site you guys recommend Stunnel as an option >>>> to complement haproxy for ssl. >>>> >>>> Now, I know that haproxy can handle a good amount of traffic but do >>>> you have any idea about this regarding Stunnel? Ssl will be used only >>>> in few parts of the site but I still want know that Stunnel wont be my >>>> bottle neck in the future. >>>> >>> >>> In my experience, it performs quite well. You can get around 2000 >>> connections per second per 2GHz CPU core in thread mode. This assumes >>> that keys are not renewed too often, of course. The thread model will >>> inevitably limit the number of concurrent connections. I remember >>> having performed some tests around a few thousand concurrent connections >>> (around 2-3000), but you will probably not get much higher than that in >>> this model. Also, SSL connections require heavy memory buffers, so if >>> you're planning on reaching such numbers, you should definitely run >>> some tests first to find the memory usage associated with your load. >>> I may be wrong, but I recall numbers around 64kB per connection, plus >>> the thread-local context. >>> >>> The advantage of using a TCP-level component such as stunnel is that >>> it is completely scalable. Need more connections ? run it on multiple >>> machines with LVS or haproxy in front of it and you're done. >>> >>> Regards, >>> Willy >>> >>> >>> >> > > >
-- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein