CarlAmko
commented
11 months ago Methodology
- Use VisualVM to evaluate CPU, memory, thread count, class loads/unloads, and more
- Evaluate various scenarios in which end users might use the Java SDK
Tests
Test 1: Simple TCP Tunnel
Goal
- Check for general performance anomalies while idling
- Check for performance anomalies associated with accepting/closing connections to a TCP tunnel
Timeline
- Thread pool of 10
- Idled for ~10 minutes
- Began opening TCP connections after ~11 minutes
Observations
- Heap consistently increased by ~2.1 MB every 20 seconds
- GC successfully brought heap size back down to baseline each time (~3.8 MB)
- Thread pool correctly lazy allocated 10 threads for handling connections. Further connections used previously opened threads in the pool.
Test 2: Repeatedly open and close TCP Tunnel
Goal
- Check for performance anomalies associated with starting/stopping new agent sessions
Timeline
- Ran for ~5 minutes
Observations
- Saw a similar heap growth pattern as Test 1
- GC resulting in heap reduction back to baseline (as in Test 1)
- No anomalies observed
Test 3: Spam traffic to backend-less HTTP Tunnel wrapped in TunnelServerSocket
Goal
- Check for performance anomalies associated with HTTP tunnels
- Check for performance anomalies associated with
TunnelServerSockets
Timeline
- Ran for ~6 minutes
- Made requests to open HTTP tunnel endpoint continuously throughout the timeline
Observations
- Heap allocation appeared to increase more rapidly as compared to TCP tunnel when accepting connections
- GC once again brought the heap down to baseline levels
- No anomalies observed
We should ensure that we aren't accidentally leaking memory anywhere. We should profile some sample sessions using various features of the SDK to determine what our memory footprint looks like.