bin/jmeter-report

#! /bin/sh

##   Licensed to the Apache Software Foundation (ASF) under one or more
##   contributor license agreements.  See the NOTICE file distributed with
##   this work for additional information regarding copyright ownership.
##   The ASF licenses this file to You under the Apache License, Version 2.0
##   (the "License"); you may not use this file except in compliance with
##   the License.  You may obtain a copy of the License at
## 
##       http://www.apache.org/licenses/LICENSE-2.0
## 
##   Unless required by applicable law or agreed to in writing, software
##   distributed under the License is distributed on an "AS IS" BASIS,
##   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
##   See the License for the specific language governing permissions and
##   limitations under the License.

# The following should be reasonably good values for most tests running
# on Sun JVMs. Following is the analysis on which it is based. If it's total
# gibberish to you, please study my article at
# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
#
# JMeter objects can generally be grouped into three life-length groups:
#
# - Per-sample objects (results, DOMs,...). An awful lot of those.
#   Life length of milliseconds to a few seconds.
#
# - Per-run objects (threads, listener data structures,...). Not that many 
#   of those unless we use the table or tree listeners on heavy runs.
#   Life length of minutes to several hours, from creation to start of next run.
#
# - Per-work-session objects (test plans, GUIs,...).
#   Life length: for the life of the JVM.

# This is the base heap size -- you may increase or decrease it to fit your
# system's memory availablity:
HEAP="-Xms256m -Xmx256m"

# There's an awful lot of per-sample objects allocated during test run, so we
# need a large eden to avoid too frequent scavenges -- you'll need to tune this
# down proportionally if you reduce the HEAP values above:
NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"

# This ratio and target have been proven OK in tests with a specially high
# amount of per-sample objects (the HtmlParserHTMLParser tests):
# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%"

# Think about it: trying to keep per-run objects in tenuring definitely
# represents a cost, but where's the benefit? They won't disappear before
# the test is over, and at that point we will no longer care about performance.
#
# So we will have JMeter do an explicit Full GC before starting a test run,
# but then we won't make any effort (or spend any CPU) to keep objects
# in tenuring longer than the life of per-sample objects -- which is hopefully
# shorter than the period between two scavenges):
#
TENURING="-XX:MaxTenuringThreshold=2"

# This evacuation ratio is OK (see the comments for SURVIVOR) during test
# runs -- no so sure about operations that bring a lot of long-lived information into
# memory in a short period of time, such as loading tests or listener data files.
# Increase it if you experience OutOfMemory problems during those operations
# without having gone through a lot of Full GC-ing just before the OOM:
# EVACUATION="-XX:MaxLiveObjectEvacuationRatio=20%"

# PermSize is a scam. Leave it like this:
PERM="-XX:PermSize=64m -XX:MaxPermSize=64m"

# Finally, some tracing to help in case things go astray:
DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"

SERVER="-server"

ARGS="$SERVER $HEAP $NEW $SURVIVOR $TENURING $EVACUATION $PERM $DEBUG"

java -server -jar `dirname $0`/ApacheJMeter.jar report "$@"