Envoy memory optimization: do better filter_chain_match organization

[phylake]

Contour creates a filter_chain_match with a single FQDN in server_names for every FQDN. It also provides TLS delegation which we use heavily. The problem is that the same tls_context and filters are copied in each filter_chain.

We reorganized filter_chain_match creation to aggregate server_names that reference the same secret name and saw a memory reduction of 40+ GiB to ~250 MiB in Envoy

This non-optimal construction of filter_chain_match plus #1635 plus envoyproxy/envoy#7923 came together to cause our months-long issue of Envoy being oom-killed

[phylake]

Forgot to mention: you might think it's better to aggregate FQDNs by cert content (i.e. a digest), or inspect the cert and aggregate by Common Name. The latter was our first approach but it was confounded by envoyproxy/envoy#6767

[dharmab]

aggregate by Common Name

What about Subject Alternative Names? That aggregation could get tricky.

[dharmab]

There's also a corner case for different certs issued for the same names by different PKIs (think internal/enterprise CAs).

[davecheney]

Thank you for your issue.

We reorganized filter_chain_match creation to aggregate server_names that

reference the same secret and saw a memory reduction of 40+ GiB to ~250 MiB in Envoy Would you be willing to contribute that change to the project?

…

On Sat, 5 Oct 2019 at 02:54, Dharma Bellamkonda ***@***.***> wrote: There's also a corner case for different certs issued for the same names by different PKIs (think internal/enterprise CAs). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1636?email_source=notifications&email_token=AAABYA5CU4OTSM4ZH7WSWHDQM5YN7A5CNFSM4I5R5HV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMIJZA#issuecomment-538477796>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABYAZZFI4GIXJX65JNABDQM5YN7ANCNFSM4I5R5HVQ> .

[jpeach]

FYI, we organized the filter chains differently in 1.4 to enforce SNI binding semantics. This strongly binds a SNI server name to the corresponding routes, but I expect that this has some negative effect on Envoy resources, since there are now more HttpConnectionManagers.