[squid-dev] [PATCH] Fast SNI peek

[Alex Rousskov]

On 05/13/2016 11:07 AM, Christos Tsantilas wrote:

> mode | trunk | fast-sni
> SS1     100%     100%
> SS2      22%      69%
> SS3      16%      26%

The above [slightly adjusted by me] table needs an explanation and a few
disclaimers.

SSN in the first column means "splicing at SslBump stepN". That is, we
have tested recent trunk and fast-sni branch code using these three
SslBump configurations:

  # SS1 (baseline):
  ssl_bump splice all

  # SS2 (peek at SNI -- the focus of this project):
  ssl_bump peek step1
  ssl_bump splice all

  # SS3 (peek at SNI then peek at the server certificate):
  ssl_bump peek step1
  ssl_bump peek step2
  ssl_bump splice all

The percentage shown is "Squid performance" compared to SS1/baseline
where no peeking is performed. Higher numbers are better.

For example, the SS2 test shows that trunk SNI peeking performance is
only about 20% of the "immediately splice everything without peeking"
baseline. In other words, trunk wastes ~80% of performance on SNI
peeking. The optimized version loses only about 30%, approaching 70% of
"ideal" performance.

Please note that SS3 includes certificate validation so it is not an
estimate of step1+2 peeking performance alone; there were even DNS
requests during step3 in our rough tests. This could be perfected
further, but since our focus is on SNI peeking (SS2), we did not polish.
The significant overheads of those additional activities probably
explain why make SS3 trunk and fast-sni performance do not differ as
much as performance during SS2.

Absolute performance of trunk and fast SNI branch during SS1 tests was
about the same, so 100% baseline is the same for both code flavors and
all the reported percentages can be compared with each other.

These results are based on a micro-test using a best-effort Polygraph
workload (i.e., each Polygraph robot is configured to send the next
requests only after getting a response to the previous one). There were
1000 robots and 1000 origin servers during these tests. We minimized
irrelevant activity by sending only HTTPS HEAD requests and intercepting
SSL traffic (i.e., no CONNECTs). We are publishing percentages and not
absolute request rates or response times that do not estimate true
sustained performance in a realistic environment due to these
simplifications. Suffice to say that Squid was doing more than 1000
HTTPS requests per second in all these tests.

The results Christos shared did not come from the very last version of
trunk (currently untestable anyway) and fast SNI branches, but they
should be within a few percentage points of the latest code.


Cheers,

Alex.