JMeter example source code file (jmeter)

This example JMeter source code file (jmeter) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" ^TM.

Java - JMeter tags/keywords

asf, full, heap, heap, jmeter, license, license, life, life, see, survivor, survivor, this, you

The JMeter jmeter source code

#! /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
##
##   ==============================================


# 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="-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 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 -- not 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%"

# Avoid the RMI-induced Full GCs to run too frequently -- once every ten minutes
# should be more than enough:
RMIGC="-Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000"

# 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"

# Always dump on OOM (does not cost anything unless triggered)
DUMP="-XX:+HeapDumpOnOutOfMemoryError"

SERVER="-server"

ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $EVACUATION $RMIGC $PERM"

java $ARGS $JVM_ARGS -jar `dirname $0`/ApacheJMeter.jar "$@"