Re: [Openvpn-users] Re: Re: Scalability?

[Mario Gonzalez <twsmapg@xxxxxxxxx>]

On Wed, 2005-03-02 at 02:42 -0600, Charles Duffy wrote:
> On Wed, 02 Mar 2005 08:51:45 +0100, Mario Gonzalez wrote:
> 
> > What I was thinking of was more concerning the hardware requirements for
> > such a large number of clients. What would the memory footprint and CPU
> > load be? How much would we need to keep in memory for each connection?
> 
> There's another post I wrote a while ago that seems to drop into the
> ether. It didn't include any hard numbers -- but on doing a bit of
> very light testing, it appears that the marginal memory use for each
> connecting client (on Linux ia32) is about 132K. That means that 10,000
> clients will require about 1.3GB of RAM -- nothing to sniff at, but by no
> means unrealistic either.

Ok. This sounds quite promising. I will be doing some preliminary tests
this week (IF I can get it up and running).


> 
> On Tue, 2005-03-01 at 20:33 +0000, Jamie Lokier wrote:
> > I suspect he means the CPU load of the public-key crypto and
> > certificate checking at run time.  With 10000 clients, that's a lot of
> > calculations.
> 
> I'd expect he'd probably be okay with a beefy enough server once
> OpenVPN's multithreading support is back in place -- particularly if he
> boosts the key renegotiation interval, or (even better) has a
> client-connect script adding some random fuzz to the renegotiation
> interval (so as to stagger renegotiations even if all the clients
> initially connect at the same time).
> 
> There still might be some trouble as everyone reconnects after downtime
> or a like event, but my guess is that it'd be workable. Be useful to
> know a bit more about what he's trying to do (and thus how critical it
> is for clients to reconnect promptly following downtime) to offer more
> suggestions -- but one could conceive of having the client instances
> configured to exit when disconnected from the server and running in a
> supervised scripting loop that places a random amount of delay before
> restarting the client instance; this would help to avoid the
> everyone-pile-on-the-server effect.


The clients in question sends heartbeats/state information every 10
seconds or so. I think it would be acceptable to miss a beat, but not
several in a row. After an event it is not that critical that all the
clients get connected immediately, so we will probably implement some
kind of delay to spread the load.
We will have to read up a bit on the failover and load-sharing issues,
as I think we are aiming for 100% uptime :-)

mario;


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users