-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/14 22:52, Les Mikesell wrote: > On Wed, Aug 6, 2014 at 3:36 PM, David Sommerseth > <openvpn.l...@topphemmelig.net> wrote: >> >>> For the typical road-warrior scenario (one server, many >>> clients) you are probably right that a single user won't >>> benefit much from data-channel threading. However, in a >>> high-capacity site-to-site link, many concurrent connection by >>> many users are handled by a single connection instance. In this >>> case threading would enable processing multiple network packets >>> concurrently. Though that does not speed up processing of a >>> single packet, it will speed up the total connection almost >>> linear to the number of cores. >> >> +1 > > Don't you really want to throw this case at hardware ssl offload?
Yes, but the key exchange accelerators (for ex. RSA accelerators) isn't that common. More often these days you have CPUs with AES-NI instructions support, but afaik, they only cover AES symmetric encryption and decryption operations. >> Even though it might look easier to implement a solution similar >> to Apache's prefork model, I'm not convinced that approach will >> be easier to implement in OpenVPN's context. Plus, if you start >> adding more processes than cores, the result will be worse. > > Maybe - you are the code expert here, but doesn't this mean you > either have to start from scratch or find every possible thread > contention in the code? Or lock to the point that you essentially > serialize anyway? Not necessarily completely from scratch. But there will definitely to be some challenges of course with mutex locking when threads wants to access the same memory regions. However, that is most likely less intrusive and complex than to basically needing to re-write the event handler which schedules that each client gets their "time slice" in OpenVPN. OpenVPN's event handling the only thing which makes OpenVPN tackle more clients at the same time, inside the same process/thread. The OpenVPN implementation is also quite different from your apache pre-fork suggestion, where the connection to a web server is closed after having served a simple request with limited amount of data. If you have 100 clients downloading 500MB of data, I'd bet you'll easily see the need to increase the number of threads/processes in Apache to avoid new connections to be rejected. Likewise, if you have 100 clients connecting 10 times retrieving data in parallel, this also is a stressful moment for the web-server. This doesn't happen in OpenVPN, because each client gets a "time slice" before OpenVPN serves others again. In addition, Apache can give quite good throughput, but the latency can be more unpredictable, which is normally not an issue when you download data. And if it is latency sensitive, the client have often implemented some kind of buffering. Such buffering is quite impossible to do on a VPN connection. But by giving each client a slice of processing time, the latency gets more predictable and the throughput is spread more evenly among the clients. >> Yes, splitting up the tasks OpenVPN does over multiple >> threads/processes is a harder task. But I feel quite confident >> that's the approach which will scale best. > > Given that scaling beyond one CPU hasn't been a priority at all so > far, does the 'theoretical best' approach justify the debugging > complexity? The complexity of implementing a pre-forked model would actually be far more complex than the alternative. And in addition, there is a need for a SSL state manager, which keeps tracks of the SSL keying material for each client, no matter which approach is used. OpenVPN does already have such a state manager, but it's fairly simple because it only needs to process each request one client by one client. - -- kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPjTVAACgkQDC186MBRfrrdtACdHL9eIx1bJ+WrAFamQo4Lu3KQ KdcAnRPsM2AvVSZd40Pud2AaSBiScoIh =F7PT -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
