Jmeter View Result Tree crashes with a large payload

[gianhub16]

Expected behavior

No response

Actual behavior

No response

Steps to reproduce the problem

When a request with a long payload is sent (for example with a base64 file code), when I click on this request on the View Result Tree crashes and I am forced to terminate jmeter.
Sometimes jmeter responds but only after several minutes.

I've tried with this in jmeter.properties, set jsyntaxtextarea.linewrap=false
No changes

JMeter Version

5.6.2

Java Version

No response

OS Version

No response

[linvaux]

upload jmeter.log

[gianhub16]

jmeter (ok).log

[linvaux]

@gianhub16 I mean upload jmeter error log when your jmeter runs crash

[gianhub16]

This is the error that is returned when I forcibly terminate JMeter otherwise it gets stuck.

[linvaux]

Try to config JVM heap -Xms2g -Xmx4g，and threadgroup config 1 thread
but , i suggest do not use GUI mode to run test， with Non-GUI

[gianhub16]

I had already made a modification on JVM Heap config. I set as you say but nothing changes.

I am interested in GUI mode because I would like to analyze request and response. The problem is only detected with the View Result Tree listener in calls with a fairly long payload.

Would it be possible to fix this issue?

[linvaux]

could you share you jmx?

[gianhub16]

You can try simply by inserting in the payload of a request a base64 code of a file about 1/2MB in size

[gianhub16]

By the way, unfortunately if you don't read the contents from the file via java string for example, you can't even paste the text of a 1MB base64.
Try putting a 1MB pdf file encoded in base64 into the payload of a sample POST HTTP Request.
JMeter will crash.
Could you try to solve it?

[polarnik]

# Maximum size of HTML page that can be displayed; default=10 MB
# Set to 0 to disable the size check and display the whole response
#view.results.tree.max_size=10485760

# UI gets unresponsive when response contains very long lines,
# So we break lines by adding artificial line breaks
# The break is introduced somewhere in between soft_wrap_line_size..max_line_size
# We try to break on word boundaries first
#view.results.tree.max_line_size=110000
#view.results.tree.soft_wrap_line_size=100000

https://github.com/apache/jmeter/blob/master/bin/jmeter.properties#L1193C1-L1203C46

You can use the settings, for example:

view.results.tree.max_size=10000
view.results.tree.max_line_size=1000
view.results.tree.soft_wrap_line_size=1000

[polarnik]

Is your Base64 string a long-long line without any line breaks?

[gianhub16]

@polarnik

I have the same issue despite setting the parameters on jmeter.properties

Is your Base64 string a long-long line without any line breaks?

encoded-20240921162343.txt

I attach an example of a base64 string within the text file.

[polarnik]

Try putting a 1MB pdf file encoded in base64 into the payload

Try to use the tab: File

https://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request

File Path:
Name of the file to send. If left blank, JMeter does not send a file, if filled in, JMeter automatically sends the request as a multipart form request.
When MIME Type is empty, JMeter will try to guess the MIME type of the **given file. **
If it is a POST or PUT or PATCH request and there is a single file whose 'Parameter name' attribute (below) is omitted, then the file is sent as the entire body of the request, i.e. no wrappers are added.

Fill two columns only:

• File path
• MIME
  but don't will the column Parameter name

As a result you will send 1 MByte, 10 MBytes, 100 MBytes witout any limits and memory overheads.

About memory overheads -- yes, you can put the long content into the JMX file, as a result the file size will be 10 MBytes for example. A file content in memory is a UTF-16 String, it will have a size ~ 40 MByte. Each thread will have a JMX content copy. Xmx1g is a HEAP Size for 1000 / 40 = 25 threads, but 100 threads will try to allocate 4g of HEAP, it will be a root cause of the OOM Error

The same script without request contents, but with the file links only, will work well without the OOM Error

[polarnik]

Thanks! I see

You use a long line.

Try to combine two peaces of advice:

• HTTP Request / File / File path without Parameter name attribute. -- It will reduce the JMX file size
  • instead of HTTP Request / Request Body
• user.properties -- it will reduce memory allocations during debugging sessions
  • view.results.tree.max_size=10000
  • view.results.tree.max_line_size=1000
  • view.results.tree.soft_wrap_line_size=1000

[polarnik]

The last hint is about java param:

-XX:+UseStringDeduplication 

Try to put it into the JVM_ARGS env variable
https://github.com/apache/jmeter/blob/master/bin/jmeter.bat

All JMX file content strings are the same strings. New Java versions can reduce memory allocations for the similar strings

[polarnik]

@vlsi
Can I put the option

-XX:+UseStringDeduplication

into the files:

• https://github.com/apache/jmeter/blob/master/bin/jmeter.bat
• https://github.com/apache/jmeter/blob/master/bin/jmeter.sh
• ...
  ?

[polarnik]

JMeter code base doesn't use the keyword String.intern()
https://github.com/search?q=repo%3Aapache%2Fjmeter+intern&type=code

I will try to use it for the JMX String content. I will find a source code files via memory profiling

[gianhub16]

Any other solutions/workaround?

[FSchumacher]

@gianhub16 would you be able to build the PR for yourself and test your test plan with that fix?

[gianhub16]

,

[FSchumacher]

@vlsi Can I put the option

-XX:+UseStringDeduplication

into the files:

* https://github.com/apache/jmeter/blob/master/bin/jmeter.bat

* https://github.com/apache/jmeter/blob/master/bin/jmeter.sh

* ...
  ?

You can use that option. A better place for personalized java options would be bin/setenv.sh or bin/setenv.bat.
Extra java options can be set via the env variable JVM_ARGS.

Note, that setting that option will have no effect on this problem, but may reduce memory consumption nonetheless.