Skip to content

Envoyfilter matching performance optimization#19786

Merged
istio-testing merged 9 commits intoistio:masterfrom
hzxuzhonghu:envoyfilter-proxy-match
Dec 27, 2019
Merged

Envoyfilter matching performance optimization#19786
istio-testing merged 9 commits intoistio:masterfrom
hzxuzhonghu:envoyfilter-proxy-match

Conversation

@hzxuzhonghu
Copy link
Copy Markdown
Member

@hzxuzhonghu hzxuzhonghu commented Dec 25, 2019

  1. move the config patch's proxy match to the top level , this is to reduce the calling of proxyMatch times,

  2. merging envoyfilterWrappers in getting procedure from push context

  3. The performance is improved.

Before:

$ go test  -bench=. -benchtime 30s
goos: linux
goarch: amd64
pkg: istio.io/istio/pilot/pkg/networking/core/v1alpha3/envoyfilter
BenchmarkTelemetryV2Filters-4   	  176700	    208609 ns/op

With this pr

$ go test  -bench=. -benchtime 30s
goos: linux
goarch: amd64
pkg: istio.io/istio/pilot/pkg/networking/core/v1alpha3/envoyfilter
BenchmarkTelemetryV2Filters-4   	  415954	     87968 ns/op

@hzxuzhonghu hzxuzhonghu requested a review from a team as a code owner December 25, 2019 09:57
@istio-testing istio-testing added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Dec 25, 2019
@googlebot googlebot added the cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. label Dec 25, 2019
},
{
Name: "new-vhost",
Domains: []string{"domain:80"},
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why remove?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "new-vhost" is a new added VirtualHost, we should not allow mutating a user specified patch.

var got interface{}
b.ResetTimer()
for n := 0; n < b.N; n++ {
copied := proto.Clone(l)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did you have to add this? This is suspicious, are we modifying the EnvoyFitlter somewhere? I don't think we should be doing that, caused a lot of problems doing a similar thing with VS

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bug fix, as i tested, i found that the running time is grown as the times increase. It is because, the listener length is growing each time.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be seen as the memory leaks

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure this is a bug in listener patch code. We shouldn't be modifying the listeners we pass in. Otherwise we will run into issues. For example, if we have some filter as constant and we modify that, its going to be very bad

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe its not an issue... what do you think?

@@ -724,34 +736,32 @@ func TestApplyListenerPatches(t *testing.T) {
// This benchmark measures the performance of Telemetry V2 EnvoyFilter patches. The intent here is to
// measure overhead of using EnvoyFilters rather than native code.
func BenchmarkTelemetryV2Filters(b *testing.B) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this ~3x faster now? The proxy IS a match, so shouldn't there be no improvement?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually the most important part is i moved the proxyMatch to the PushContext.EnvoyFilters, which is actually called once per proxy. But currently, the times is correlated to the number of listeners, patches, filterchains, networkfilters, etc.

@howardjohn
Copy link
Copy Markdown
Member

I do see CPU usage go from 600m to 500m with this patch on a cluster

@howardjohn
Copy link
Copy Markdown
Member

2019-26-12_11-16-30

@howardjohn
Copy link
Copy Markdown
Member

lgtm if we can explain why its now faster, and fix the extra return in the test (unless there is a reason for it?). Thanks!

@hzxuzhonghu
Copy link
Copy Markdown
Member Author

Thanks for the e2e performance test. And the perfomrance improvement is related to Reducing the proxyMatch calling times a lot

@howardjohn
Copy link
Copy Markdown
Member

I don't think proxy match is that cpu intensive though? I would be interested to see profiles before and after this change. I can run it myself though

@howardjohn
Copy link
Copy Markdown
Member

Ah so the main performance benefit is actually merging all the patches. It makes this get called only one time:

if err := ptypes.UnmarshalAny(filter.GetTypedConfig(), hcm); err != nil {

@istio-testing istio-testing merged commit a327090 into istio:master Dec 27, 2019
@hzxuzhonghu hzxuzhonghu deleted the envoyfilter-proxy-match branch December 27, 2019 06:58
nmittler added a commit to nmittler/istio that referenced this pull request Dec 27, 2019
istio-testing pushed a commit that referenced this pull request Dec 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/networking area/perf and scalability cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants