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.

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

Bug 59882 : JMeter memory allocations reduction #217

Closed
wants to merge 13 commits into
base: trunk
from

Conversation

Projects
None yet
1 participant
@benbenw

benbenw commented Jul 18, 2016

I've been profiling jmeter memory allocation under different conditions
the PR linked to this bug gives substantial improvements.

Gain really depends on the test but in the worst case (compressed content, no embedded resources) it's about 15% less allocations (in bytes)
When not compressed (no embedded resources) and if content-length is sent by the server my test gives 30% reduction in bytes allocated
As always YMMV but this PR is always a win in all my different tests.

Reduction in memory allocated comes from
Better usage of ByteArrayOutputStream by

  • directly accessing the buffer instead of copying it
  • or by using the commons-lang implementation which avoid copying memory around when extending the buffer
  • or by creating the string directly from the buffer instead of a temporary copy

Avoid unneeded string concatenation due to missing log.isDebugEnabled()
if possible use httpclient CharArrayBuffer to avoid memory allocations
Do not create unneeded silent exceptions
Do not allocate 2 empty iterators on each call to executeSamplePackage

  • LinkedList.iterator() is a stinky monkey. Also see HTTPCORE-361

Set better default size to StringBuilder buffers
improve JOrphanUtils#replaceAllChars : provides a fast path which does not allocate memory
etc..

Remark :
When using ssl, jsse is a major source of unneeded allocation !!!! (sun.security.ssl.SSLContextImpl#getDefaultCipherSuiteList(boolean))
https://bugs.openjdk.java.net/browse/JDK-8133070 should improve the situation (I did not test it)
the title of the bug is misleading as it's also about an internal cache beeing cleared on each method call.

benbenw added some commits Jul 12, 2016

Profiling show that jmeter is doing a lot of unneeded memory allocation.
use a specialized version of ByteArrayOutputStream which return its
internal buffer when possible, this remove an allocation of
byte[response size] when the content length is known and respected.
do not create a buffer + copy when generating a md5 signature
lazily allocate the ByteArrayOutputStream buffer which is not needed
when it's an empty response
getResponseHeaders is allocating too much memory
try to give a better default size to the stringbuilder
use httpclient CharArrayBuffer to avoid memory allocations
in the jmx file you often find :
<stringProp name="HTTPSampler.port"></stringProp>

this makes getPortIfSpecified throws a "silent" exception
this is bad as it's slow and allocates memory for the trace
do not allocate 2 empty iterators on each call to executeSamplePackage.
It's always >5% of the memory allocated during my tests
add a fast path which does not allocate memory when there is no
arguments.
construct the buffer with a better initial size to avoid re-allocations
improve JOrphanUtils#replaceAllChars
provides a fast path which does not allocate memory

asfgit pushed a commit that referenced this pull request Jul 31, 2016

re-use pattern when possible
Contributed by Benoit Wiart (b.wiart at ubik-ingenierie.com)

Part of PR #217 on github.

git-svn-id: https://svn.apache.org/repos/asf/jmeter/trunk@1754660 13f79535-47bb-0310-9956-ffa450edef68

@asfgit asfgit closed this in 5f87f30 Jul 31, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment