Link to home
Start Free TrialLog in
Avatar of bigdork
bigdork

asked on

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
ASKER CERTIFIED SOLUTION
Avatar of Dave Howe
Dave Howe
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of bigdork
bigdork

ASKER

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
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
Avatar of bigdork

ASKER

Thanks Dave - I appreciate your help on my question and also the follow up question on multiplexing as well.