WILS: SSL TPS versus HTTP TPS over SSL

The difference between these two performance metrics is significant so be sure you know which one you’re measuring, and which one you wanted to be measuring. 

It may be the case that you’ve decided that SSL is, in fact, a good idea for securing data in transit. Excellent. Now you’re trying to figure out how to implement support and you’re testing solutions or perhaps trying to peruse reports someone else generated from testing. Excellent. I’m a huge testing fan and it really is one of the best ways to size a solution specifically for your environment.

Some of the terminology used to describe specific performance metrics in application delivery, however, can be misleading. The difference between SSL TPS (Transactions per second) and HTTP TPS over SSL, for example, are significant and therefore should not be used interchangeably when comparing performance and capacity of any solution – that goes for software, hardware, or some yet-to-be-defined combination thereof.

The reasons why interpreting claims of SSL TPS are so difficult is due to the ambiguity that comes from SSL itself. SSL “transactions” are, by general industry agreement (unenforceable, of course) a single transaction that is “wrapped” in an SSL session. Generally speaking one SSL transaction is considered:

1. Session establishment (authentication, key exchange)

2. Exchange of data over SSL, often a 1KB file over HTTP

3. Session closure

Seems logical, but technically speaking a single SSL transaction could be interpreted as any single transaction conducted over an SSL encrypted session because the very act of transmitting data over the SSL session necessarily requires SSL-related operations. SSL session establishment requires a handshake and an exchange of keys, and the transfer of data within such a session requires the invocation of encryption and decryption operations (often referred to as bulk encryption).

Therefore it is technically accurate for SSL capacity/performance metrics to use the term “SSL TPS” and be referring to two completely different things.

This means it is important that whomever is interested in such data must do a little research to determine exactly what is meant by SSL TPS when presented with such data. Based on the definition the actual results mean different things. When used to refer to HTTP TPS over SSL the constraint is actually on the bulk encryption rate (related more to response time, latency, and throughput measurements), while SSL TPS measures the number of SSL sessions that can be created per second and is more related to capacity than response time metrics. It can be difficult to determine which method was utilized, but if you see the term “SSL ID re-use” anywhere, you can be relatively certain the test results refer to HTTP TPS over SSL rather than SSL TPS. When SSL session IDs are reused, the handshaking and key exchange steps are skipped, which reduces the number of computationally expensive RSA operations that must be performed and artificially increases the results.

As always, if you aren’t sure what a performance metric really means, ask. If you don’t get a straight answer, ask again, or take advantage of all that great social networking you’re doing and find someone you trust to help you determine what was really tested. Basing architectural decisions on misleading or misunderstood data can cause grief and be expensive later when you have to purchase additional licenses or solutions to bring your capacity up to what was originally expected.

WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND.

       

AddThis Feed Button Bookmark and Share

Published Feb 03, 2010
Version 1.0
  • James - To count it as new conns per second you'd want to eliminate the data transfer.

     

     

    Wildcard - TPS refers to an entire transaction, from handshake to data transfer, to closure. It would be 51 TPS, as you correctly surmise (assuming underlying protocol is HTTP 1.1) although what you end up testing is two things: bulk encryption/decryption rates (for objects received over a persistent connection) with a variable number of handshakes (depending on how many objects are allowed to be retrieved over a single connection).

     

     

    SSL is very difficult to quantify because there are two different functions being used: handshaking exchanges keys and performs different RSA operations than the bulk encryption/decryption performed within that SSL session.

     

     

  • @PW

     

     

    I can't speak for others definitively, but the most commonly used cipher for web sites is still RC4-MD5. Folks are beginning to move to AES-based ciphers but the majority of sites using SSL today are still using RC4-MD5.

     

     

    So when we test we test against both RC4-MD5 and AES256-SHA ciphers.

     

     

    Lori
  • @DB -

     

     

    Enforcement happens when the flow is created and at completion of client-side handshakes. As long as the connection remains open, it will count as 1. However, renegotiations will count too.

     

     

    Hope that is helpful!

     

     

    Lori