Any questions? Post'em

Hi Jeff,

 

 

Concurrent SSL connections was not tested. In general, the "hard limit" for SSL concurrency is based on the amount of memory that can be allocated to store SSL connection information. The practical limit for SSL concurrency depends on your threshold for latency.

 

 

As concurrency increases so do the processing requirements for handling each connection. Depending on the particular implementation, factors that contribute to this increase in per-connection overhead may include: connection hash table collisions, memory fragmentation, session cache overflows, connection maintenance functions (checking for connection timeouts, for example), and more.

 

 

Depending on implementation, the effects of increased overhead may start to appear with thousands, tens of thousands, or hundreds of thousands of connections. It's highly dependent on vendor implementation.

 

 

All things considered, you're more likely to hit a "practical limit" that causes poor performance (high latency) than you are to hit a "hard limit" based on memory limits. With that in mind, the numbers that vendors have published thus far are based "hard limits".

 

 

Without having more exact information to give you, I'd like to point out that you're likely to see practical performance limits that mirror the other SSL performance recorded in the performance report. In other words, if vendorX can process 48,000 SSL TPS, vendorY 28,000, and vendorZ 15,000, it's reasonable to expect vendorX has more processing power dedicated to SSL, and thus is likely to have an advantage in practical SSL concurrency as well.

 

 

I hope that helps. Good luck!

 

 

Mike Lowell