Envoyfilter matching performance optimization#19786
Envoyfilter matching performance optimization#19786istio-testing merged 9 commits intoistio:masterfrom
Conversation
pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch_test.go
Outdated
Show resolved
Hide resolved
| }, | ||
| { | ||
| Name: "new-vhost", | ||
| Domains: []string{"domain:80"}, |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This can be seen as the memory leaks
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { | |||
There was a problem hiding this comment.
Why is this ~3x faster now? The proxy IS a match, so shouldn't there be no improvement?
There was a problem hiding this comment.
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.
|
I do see CPU usage go from 600m to 500m with this patch on a cluster |
|
lgtm if we can explain why its now faster, and fix the extra |
|
Thanks for the e2e performance test. And the perfomrance improvement is related to |
|
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 |
|
Ah so the main performance benefit is actually merging all the patches. It makes this get called only one time: |
The crash was introduced by istio#19786
The crash was introduced by #19786

move the config patch's proxy match to the top level , this is to reduce the calling of proxyMatch times,
merging envoyfilterWrappers in getting procedure from push context
The performance is improved.
Before:
With this pr