blob: c015226ce9a4e2772d0347e25fbd4b6945c13bed [file] [log] [blame]
#! /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.
## ==============================================
## Environment variables:
## JVM_ARGS - optional java args, e.g. -Dprop=val
##
## e.g.
## JVM_ARGS="-Xms512m -Xmx512m" jmeter etc.
##
## ==============================================
# Minimal version to run JMeter
MINIMAL_VERSION=1.7.0
# Check if Java is present and the minimal version requirement
_java=`type java | awk '{ print $ NF }'`
CURRENT_VERSION=`"$_java" -version 2>&1 | awk -F'"' '/version/ {print $2}'`
minimal_version=`echo $MINIMAL_VERSION | awk -F'.' '{ print $2 }'`
current_version=`echo $CURRENT_VERSION | awk -F'.' '{ print $2 }'`
if [ $current_version ]; then
if [ $current_version -lt $minimal_version ]; then
echo "Error: Java version is too low to run JMeter. Needs at least Java >= ${MINIMAL_VERSION}."
exit 1
fi
else
echo "Not able to find Java executable or version. Please check your Java installation."
exit 1
fi
JMETER_OPTS=""
case `uname` in
Darwin*)
# Add Mac-specific property - should be ignored elsewhere (Bug 47064)
JMETER_OPTS="-Xdock:name=JMeter -Xdock:icon="`dirname $0`/../docs/images/jmeter_square.png" -Dapple.laf.useScreenMenuBar=true -Dapple.eawt.quitStrategy=CLOSE_ALL_WINDOWS"
;;
esac
# resolve links - $0 may be a softlink (code as used by Tomcat)
# N.B. readlink would be a lot simpler but is not supported on Solaris
PRG="$0"
while [ -h "$PRG" ]; do
ls=`ls -ld "$PRG"`
link=`expr "$ls" : '.*-> \(.*\)$'`
if expr "$link" : '/.*' > /dev/null; then
PRG="$link"
else
PRG=`dirname "$PRG"`/"$link"
fi
done
PRGDIR=`dirname "$PRG"`
# 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
# Original page has disappeared, it is now only available at:
# https://web.archive.org/web/20060614151434/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 availability:
HEAP="-Xms512m -Xmx512m"
# 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 modify the HEAP values above, below example is fine for 512m of Heap:
# 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"
# Java 8 remove Permanent generation, don't settings the PermSize
if [ $current_version -lt "8" ]; then
# Increase MaxPermSize if you use a lot of Javascript in your Test Plan :
PERM="-XX:PermSize=64m -XX:MaxPermSize=128m"
fi
CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
# Finally, some tracing to help in case things go astray:
#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
# Always dump on OOM (does not cost anything unless triggered)
DUMP="-XX:+HeapDumpOnOutOfMemoryError"
SERVER="-server"
ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"