mirror of https://github.com/apache/activemq.git
81 lines
3.6 KiB
Bash
81 lines
3.6 KiB
Bash
#! /bin/sh
|
|
|
|
## $Id: jmeter,v 1.27 2005/03/18 15:26:54 mstover1 Exp $
|
|
## Copyright 2001-2004 The Apache Software Foundation
|
|
##
|
|
## Licensed 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%"
|
|
|
|
# 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"
|
|
|
|
SERVER="-server"
|
|
|
|
ARGS="$SERVER $HEAP $NEW $SURVIVOR $TENURING $EVACUATION $RMIGC $PERM $DEBUG"
|
|
|
|
java -server -jar `dirname $0`/ApacheJMeter.jar "$@"
|