Re: [Openvpn-users] Re: OpenVPN Server Performance (real experience)

[James Yonan <jim@xxxxxxxxx>]

Dale wrote:
> Dale <d.schultz <at> telesat.ca> writes:
>
>   
> > Charles Duffy <cduffy <at> spamcop.net> writes:
> >     
> > > I'd be interested to see what exactly your system is actually doing 
> > > that's throttling the CPU. Perhaps you could use oprofile to find out if 
> > > it's spending its time inside OpenSSL (which is the only *legitimate* 
> > > place for it to be) or somewhere else.
> > >
> > >       
> > I can look at tusing that tool, thanks.  I just want to be clear though, I'm 
> > only having CPU load issues when the network has to re-establish all the 
> > tunnels with the remotes.  I have no problems once the tunnels are up.  The 
> > CPU with 200+ tunnels running is very low in normal operating mode.  The 
> > highest I see it go is 10%, and that is when the reneg kicks in.  I need to 
> > look at the reneg option too, I'd like to get away from the 3600 seconds 
> > thing.  Can I use both reneg on a packet count and on time together?  Such 
> > that if the packet limit is not reached before the time period then the time 
> > cause a reneg?
> >
> > Thanks
> >     
>
> Hi: Does anyone know the affect of using dh4096.pem on tunnel establishment 
> compared to n=1024 or n=2048?  I didn't create this server but I did find out 
> that we are using n=4096 and it took three days to generate the DH parameters 
> on this server (3GHz Intel Xeon).
>   
The CPU time necessary for a TLS negotiation roughly varies according to 
the square of the key size.  So n=4096 will be 16 times slower than n=1024.

Practically speaking, at our current position on Moore's law curve, I 
doubt that n=4096 will buy you any real security over n=2048.

James


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