Question: Does -m mode support tcpdump parameters such as -C file_size、-c count etc

[chilli13]

ecapture是否支持如-C file_size、-c count之类的参数，限制报文个数或文件大小，达到门限后自动停止ecapture。

#ecapture tls -m pcap -i ens224np1 --pcapfile=/root/test/ssh.pcap tcp port 22
...
2024-11-19T14:37:56+08:00 INF packets saved into pcapng file. count=44
...

[cfc4n]

This is a particularly niche requirement.

But you can judge it by monitoring the ecapture running log, matching the file.count=xxx string, and sending the SIGTERM signal to the ecapture process to stop it.

[chilli13]

Thanks for reply! Can ecapture be restricted from using too many resources by adding parameter such as --count to limit the number of packets processed. It is a practical requirement in resource-sensitive scenarios. Besides sending SIGTERM signal, is there any other parameters currently available that can control ecapture to end actively?

Test cases are attached.
NGINX server runs ecapture. Nginx client concurrent access to obtain files from https tlsv1.2, 120 MBps tx traffic, ecapture single-core cpu 100%, memory (about) 600M+. Also warning message perf event ring buffer full is displayed, and dropped sampleslistSamples=xx is displayed.

virtual machine 12core 8G openEuler 22.03 (LTS-SP4) kernel 5.10.0-216.0.0.115.oe2203sp4.x86_64 1000baseT Nic
nginx server cpu affinity 2-9， ecapture affinity 10

# taskset -cp $(pgrep nginx | head -n 1)
pid 1398's current affinity list: 2-9
taskset -c 10 ecapture tls -m pcap -i ens224np1 tcp port 443  and port 4443 --pcapfile=https-performance.pcap

os environment

# ecapture -v
eCapture version:	linux_amd64:v0.8.9:6.5.0-1025-azure

# cat /etc/os-release 
NAME="openEuler"
VERSION="22.03 (LTS-SP4)"
ID="openEuler"
VERSION_ID="22.03"
PRETTY_NAME="openEuler 22.03 (LTS-SP4)"
ANSI_COLOR="0;31"

# uname -a
Linux zhm-cd-vm 5.10.0-216.0.0.115.oe2203sp4.x86_64 #1 SMP Thu Jun 27 15:13:44 CST 2024 x86_64 x86_64 x86_64 GNU/Linux

[cfc4n]

Besides sending SIGTERM signal, is there any other parameters currently available that can control ecapture to end actively?

The SIGTERM signal is a normal exit mechanism. I may consider adding an http interface in the future.

Also warning message perf event ring buffer full is displayed, and dropped sampleslistSamples=xx is displayed.

This alarm indicates that eCapture captures too much data in kernel-space and user-space consumption is too slow. Production exceeds consumption, resulting in data loss.
In your test, there are indeed a lot of network packets generated. I can't tell whether ecapture has performance problems. However, it is recommended that you try to use ecapture's keylog mode to only capture SSL KEY in user mode and not capture network packets in pcap. . At the same time, you can try to use tcpdump to capture network packets, and then use the wireshark tool to import the key and view it.

However, I noticed that you started multiple ecapture processes, which may be a wrong way to use it. Because multiple eCapture processes access the TC data of the kenel, they are repeated, which may also be the reason for low performance.

[chilli13]

Your suggestion is effective. -m keylog has better performance than -m pcap, especially in the scenario of large file download. However, in the scenario of high concurrent access of small files, the traffic is small, but the CPU consumption is still high. If you have some conclusions about ecapture performance in the future, I look forward to sharing them. Thank you
same os test environment
9MBps Tx traffic with 0.8 cpu core

[cfc4n]

The difference between large files and small files lies in the number of times HOOK points are triggered. Can you test the difference between keylog mode and without ecapture in the scenario of small file download?

[chilli13]

A simple test was conducted with 6w concurrent connections with an average outgoing bandwidth of 35Mbps~50Mpbs. The https server CPUAffinity=2-9, the sampling period was 1s, and data was collected for 10s.
The data was mainly obtained using pidstat -p $(pidof nginx | ​​tr ' ' ',') 1 1 and pidstat -p $(pidof nginx | ​​tr ' ' ',') -r 1 1
As our business scenario traffic is not large and all files are small size, under this traffic background, the performance impact of running ecapture on the https server does not seem to be obvious, but we did not test the access latency, to addtion, long connections with large files may have different effects.

Several sets of test results are provided

https server performace without ecapture

=====================
Process nginx resource consumption statistics
CPU Average: 164.90%
CPU Max: 324.00%
Memory Average: 221.40 MB
Memory Max: 222.65 MB
=====================

=====================
Process nginx resource consumption statistics
CPU Average: 198.57%
CPU Max: 354.00%
Memory Average: 160.28 MB
Memory Max: 160.70 MB
=====================

https server performace with ecapture

taskset -c 10,11 ecapture tls -m keylog --keylogfile=6w-keylog.txt

=====================
Process nginx resource consumption statistics
CPU Average: 204.70%
CPU Max: 430.00%
Memory Average: 160.45 MB
Memory Max: 160.91 MB
=====================

=====================
Process nginx resource consumption statistics
CPU Average: 194.74%
CPU Max: 357.00%
Memory Average: 160.22 MB
Memory Max: 160.45 MB
=====================

[cfc4n]

It seems that eCapture does not have a particularly large impact on performance, increasing CPU usage by approximately 20%. I think it's acceptable.

In addition, in this high-concurrency scenario, I feel that using eCapture to obtain the key is not very suitable. You can try to enable the SSLKEYLOGFILE mode of OpenSSL to record the communication key, which is a higher performance solution.