Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

performance issue: (*HTTP2Response).detect cost too much memory #700

Open
chilli13 opened this issue Dec 23, 2024 · 6 comments · May be fixed by #705
Open

performance issue: (*HTTP2Response).detect cost too much memory #700

chilli13 opened this issue Dec 23, 2024 · 6 comments · May be fixed by #705
Assignees
@yuweizzz
Labels
help wanted Extra attention is needed question Further information is requested

Comments

@chilli13
Copy link

Run ecapture -m text cost unexcepted cpu/memory resource. After using the tool perfto analyze,(*HTTP2Response).detect consumed a lot of resources. After removing this function (*HTTP2Response).detect and **(HTTP2Request).detect and recompiling the ecapture to run testcase, the performance was significantly improved.
Small files access https server with high concurrency, construct 50Mbps traffic, average memory 550M, maximum memory 677.66M. After optimization (*HTTP2Response).detect and *(HTTP2Request).detect , memory is reduced to 293.016M

Linux Server:

Device: VM
OS: [ctyunos 2.0.1]
Arch: 4.19.90-2102.2.0.0062.ctl2.x86_64 #1 SMP Thu Mar 10 03:34:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Kernel Version: 4.19

  1. modify makefile compile option to obtain symbol information
  2. perf record $(pidof ecapture)
  3. perf report
    image
@yuweizzz
Copy link
Contributor

would you describe how you optimization this function?

@chilli13
Copy link
Author

chilli13 commented Dec 23, 2024 •
edited
Loading

would you describe how you optimization this function?

I just simply removed the https2 Register function and tested it to confirm the impact of http2 detect on performance. The ecapture memory consumption was significantly reduced without http2.detect on same testcase. As our application scenario has limited resources, we will pay more attention to the performance consumption of the introduced components.

diff --git a/pkg/event_processor/http2_request.go b/pkg/event_processor/http2_request.go
index ac83c60..5dba2a8 100644
--- a/pkg/event_processor/http2_request.go
+++ b/pkg/event_processor/http2_request.go
@@ -147,7 +147,8 @@ func (h2r *HTTP2Request) Display() []byte {
 func init() {
        h2r := &HTTP2Request{}
        h2r.Init()
-       Register(h2r)
+       //tmp
+       //Register(h2r)
 }
 
 func (h2r *HTTP2Request) Reset() {
diff --git a/pkg/event_processor/http2_response.go b/pkg/event_processor/http2_response.go
index 2a2d411..82763ea 100644
--- a/pkg/event_processor/http2_response.go
+++ b/pkg/event_processor/http2_response.go
@@ -142,7 +142,8 @@ func (h2r *HTTP2Response) Display() []byte {
 func init() {
        h2r := &HTTP2Response{}
        h2r.Init()
-       Register(h2r)
+       //tmp
+       //Register(h2r)
 }

add compile option to get symbol info when using perf tool

diff --git a/functions.mk b/functions.mk
index 5b77e3b..c394ffd 100644
--- a/functions.mk
+++ b/functions.mk
@@ -44,12 +44,23 @@ define allow-override
     $(eval $(1) = $(2)))
 endef
 
+#define gobuild
+#      CGO_ENABLED=1 \
+#      CGO_CFLAGS='-O2 -g -gdwarf-4 -I$(CURDIR)/lib/libpcap/' \
+#      CGO_LDFLAGS='-O2 -g -L$(CURDIR)/lib/libpcap/ -lpcap -static' \
+#      GOOS=linux GOARCH=$(GOARCH) CC=$(CMD_CC_PREFIX)$(CMD_CC) \
+#      $(CMD_GO) build -tags '$(TARGET_TAG),netgo' -ldflags "-w -s -X 'github.com/gojue/ecapture/cli/cmd.GitVersion=$(TARGET_TAG)_$(GOARCH):$(VERSION_NUM):$(VERSION_FLAG)' -linkmode=external -extldflags -static " -o $(OUT_BIN)
+#      $(CMD_FILE) $(OUT_BIN)
+#endef
+
+# debug
 define gobuild
        CGO_ENABLED=1 \
        CGO_CFLAGS='-O2 -g -gdwarf-4 -I$(CURDIR)/lib/libpcap/' \
        CGO_LDFLAGS='-O2 -g -L$(CURDIR)/lib/libpcap/ -lpcap -static' \
        GOOS=linux GOARCH=$(GOARCH) CC=$(CMD_CC_PREFIX)$(CMD_CC) \
-       $(CMD_GO) build -tags '$(TARGET_TAG),netgo' -ldflags "-w -s -X 'github.com/gojue/ecapture/cli/cmd.GitVersion=$(TARGET_TAG)_$(GOARCH):$(VE
RSION_NUM):$(VERSION_FLAG)' -linkmode=external -extldflags -static " -o $(OUT_BIN)
+       $(CMD_GO) build -tags '$(TARGET_TAG),netgo' -gcflags "all=-N -l" \
+       -ldflags "-X 'github.com/gojue/ecapture/cli/cmd.GitVersion=$(TARGET_TAG)_$(GOARCH):$(VERSION_NUM):$(VERSION_FLAG)' -linkmode=external -ex
tldflags -static " -o $(OUT_BIN)
        $(CMD_FILE) $(OUT_BIN)
 endef

@yuweizzz
Copy link
Contributor

the h2 response detect is much complicated than h2 request, maybe we can find a new way to optimize it. could you try Register the h2 request and without Register h2 response?

@cfc4n cfc4n added help wanted Extra attention is needed question Further information is requested labels Dec 23, 2024
@yuweizzz
Copy link
Contributor

please assign it to me, I will try to fix it.

@chilli13
Copy link
Author

Register the h2 request

Register the h2 request has no noticeable impact on performance. As you would expect, the performance bottleneck should mainly be caused by h2 response

@cfc4n
Copy link
Member

cfc4n commented Dec 24, 2024

please assign it to me, I will try to fix it.

Can you tell me your solution?

@yuweizzz yuweizzz linked a pull request Dec 25, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@yuweizzz yuweizzz

Labels
help wanted Extra attention is needed question Further information is requested
Projects
None yet
Milestone
No milestone
3 participants
@cfc4n @yuweizzz @chilli13