apache / apache/jmeter

Excessive memory usage on Transaction Controller using parent sample

Open
#6,237 7 comments 0 reactions 0 assignees View on GitHub
defect to-triage
Dominant language
Java
Stars
9.5k
Forks
2.3k
Avg merge
1d 22h
Merged PRs (30d)
5

Description

### Expected behavior

When 'generate parent sample' is enabled on a Transaction Controller, it should clear the data once the transaction is finished and processed by the listeners. This is to avoid unnecessary excessive memory usage per thread.

### Actual behavior

When 'generate parent sample' is enabled on a Transaction Controller, it looks like it doesn't clean the data after the transaction is finished. When there are samplers with very large bodies (ie. large java scripts), the memory piles up for the duration of the Thread. When generate parent sample is disabled, it does clear the sample data as memory usage is significantly low

### Steps to reproduce the problem

Place 30 samplers/ HTTP requests to large objects (1MB) in a Transaction Controller with Generate parent sample enabled. With a 1 second think time in between, 30 threads, it will use up to 3 GB of memory.
When disabling the generate parent sample, it will reduce memory usage to 500MB.

Based on calculations and playing around with different values it feels like the body is kept in memory 3 times for the duration of the thread

### JMeter Version

5.6.3

### Java Version

17

### OS Version

Ubuntu

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the reported setup: 30 samplers or HTTP requests for 1 MB objects inside a Transaction Controller with Generate parent sample enabled, then compare memory use with it disabled. Trace how the Transaction Controller retains and processes parent sample data through listener handling. Done means completed transactions release unnecessary sample data and the reproduction no longer shows the reported accumulation.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
performance, testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.