There are a lot of SSL offload throughput statistics available for appliances across the internet but rarely do they detail the way they were tested we at loadbalancer.org wish to change that.
What is SSL offloading/SSL Termination?
SSL offloading is the process of moving SSL traffic decryption and encryption away from your web servers onto a centralised device, be it a loadbalancer or specific SSL offloading hardware.
The Test
You can use as many clients and back end servers as you need, to get the best results the loadbalancer/appliance should be the bottleneck. To generate the load on the test devices we wrote our own SSL test script in python. If you want a copy of it fire off an email to support@loadbalancer.org and they will be able to provide you with the latest version.
One IP address listening on port 443 using the decryption system of your choice, in our case its Stunnel. No SSL session reuse, although in the real world its a useful resource and should be implemented where possible. In this case it wont really give you a clear view of the raw horse power of the appliance. So each connection should involve a full SSL handshake and be fully closed on completion.
Then 1 internal IP listening on port 80 forwarding to HAProxy which is configured with no persistence. select a real server to direct the connection to based on weighted least connections. The backend servers should be running a web service either apache or nginx (in our case its apache) and returning a single html formatted webpage.
For Example –
You are viewing rip-test-1
The whole page is 107B in size, this page is duplicated across all of the backend servers, with the only difference being rip-test-1 is changed to reflect the server name so we have
rip-test-1
rip-test-2
rip-test-3
etc.
Each test was run for a total of 60 seconds for a total of 3 runs, using HAProxy 1.5-dev18 version, Stunnel version 4.55 and OpenSSL 1.0.1e.
A complete connection counts as a HTTPS request for the page made from a client NOT running on the loadbalancer to the 443 IP on the loadbalancer, that request is decoded and passed on to HAProxy where it decides which server to pass the request on to. The request is received by the back-end and the page is returned to HAProxy where is passed onto the program that’s doing the SSL to be re-encrypted and passed back to the client.
Throughput Results
| Date of Test | CPU | RAM | Cipher | Certificate Length | Run 1 Results | Run 2 Results | Run 3 Results |
|---|---|---|---|---|---|---|---|
| 30/10/13 | Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz | 4GB | ECDHE-RSA-AES256-SHA | 1024 bits | 3625 | 3629 | 3631 |
| 31/10/13 | Intel® Atom processor C2750 | 8GB | ECDHE-RSA-AES256-SHA | 1024 bits | 1147 | 1204 | 1220 |
| 04/11/13 | Intel(R) Xeon(R) CPU E5-2470 0 @ 2.30GHz | 8GB | ECDHE-RSA-AES256-SHA | 1024 bits | 2780 | 2778 | 2777 |
| 04/11/2013 | Intel(R) Celeron(R) CPU 440 @ 2.00GHz | 1GB | ECDHE-RSA-AES256-SHA | 1024 bits | 321 | 322 | 322 |
| 06/11/13 | Intel(R) Xeon(R) CPU X3430 @ 2.40GHz | 2GB | ECDHE-RSA-AES256-SHA | 1024 bits | 2160 | 2234 | 2236 |
| 06/11/13 | Intel(R) Atom(TM) CPU D510 @ 1.66GHz | 4GB | ECDHE-RSA-AES256-SHA | 1024 bits | 343 | 338 | 344 |
| 06/11/13 | Dual Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz | 32GB | ECDHE-RSA-AES256-SHA | 1024 bits | 6082 | 6143 | 6190 |
| 06/11/13 | Intel(R) Atom(TM) CPU S1260 @ 2.00GHz | 4GB | ECDHE-RSA-AES256-SHA | 1024 bits | 388 | 387 | 389 |
You Can Learn More About the LoadBalancer.org’s Product Line By Going to www.LoadBalancerSolutions.com/LoadBalancer-org
The original article/video can be found at SSL Offload Testing with HAProxy and Stunnel