What exactly is meant by SSL Transactions Per Second ( TPS ) in an SSL offloading scenario?

I'm evaluating content delivery / load balancing vendors and many measure their appliance's ability to perform by SSL Transactions Per Second or SSL TPS. TPS is higher when there is dedicated hardware to process SSL connections rather than just software (obviously). SSL certificates are installed or terminated on the device, the device negotiates with the client browser and typically the connection from the load balancer to the server is not encrypted.

I'm trying to determine our TPS needs based on our traffic and I don't have a clear way to translate, say requests/sec into SSL TPS. There doesn't seem to be a direct correlation.

Does TPS refer to ONLY the handshake? What happens if someone requests a secure web page with 50 references to images over HTTPS? Is that 1 plus 50 = 51 TPS?

Hutch
bigdorkAsked:
Who is Participating?
 
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
yes, that would be 51 transactions. you have to remember that the hard bit is the SSL handshake - you are using large-number math for the certificate validation step, plus for the PFS symmetric key negotiation. by contrast, the actual data traffic is trivial.

TPS is the number of ssl handshakes, regardless of bytes moved.
0
 
bigdorkAuthor Commented:
Dave thanks for the reply. Just to muddy the question a bit - I was under the impression with TCP Multiplexing that those 51 requests/sec are reduced to a smaller number meaning I don't have as many TPS as I do GETS/Sec. The vendors usually have 2 stats they advertise "Reqs/Sec" and "TPS".

Perhaps to beat the horse here - so you are ultimately saying I should evaluate how many Requests/Sec I recieve over HTTPS and that should roughly be Transactions Per Second?

I appreciate it,

Hutch
0
 
Dave HoweSoftware and Hardware EngineerCommented:
With TCP Multiplexing then multiple SSL Transactions are initiated to the offloader/balancer, which then opens a single HTTP 1.1 connection to your backend server and serializes the requests from a single IP down that one channel. as this is usually truely http rather than https, this really only saves you one tcp setup/teardown - not to be sneezed at in today's high load environments, but still not a lot. the bulk of the savings are in offloading the crypto overhead onto the balancer. Of course, if the browser itself can handle TCP Multiplexing, then multiple requests may be bundled into a single ssl transaction before they reach the balancer.

in addition, many balancers (such as the F5 "big ip" device) are also caching servers - so for a number of seconds after an initial response for (for example) a gif, further requests for the same image would be satisfied from cache and not pushed forward to your backend content hosts
0
 
bigdorkAuthor Commented:
Thanks Dave - I appreciate your help on my question and also the follow up question on multiplexing as well.
0
All Courses

From novice to tech pro — start learning today.