Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/WASdev/sample.daytrader7/llms.txt

Use this file to discover all available pages before exploring further.

DayTrader 7 ships two JMeter test plans in the jmeter_files/ directory: daytrader7.jmx (standard) and daytrader7_mojarra.jmx (for Mojarra JSF implementations). Both plans drive the full trading workload — login, logout, buy, sell, quote, portfolio, account, and account update operations — including WebSocket connections that mirror the live quote streaming feature used by the application. The test plans are parameterized via -J command-line options, making it straightforward to scale thread counts, durations, and user populations without editing the .jmx files.

​
Prerequisites

Before running the test plans, ensure the following are in place on the driver machine:
  • JMeter 3.3 or later — earlier versions are not supported.
  • WebSocket Samplers plugin by Peter Doornbosch — the test plans include WebSocket calls (WS1 and WS2) that require this plugin. Install it via the JMeter Plugin Manager, or download directly from https://bitbucket.org/pjtr/jmeter-websocket-samplers and copy the JAR to <JMETER_HOME>/lib/ext/.
  • Test plan files — copy both daytrader7.jmx and daytrader7_mojarra.jmx from the jmeter_files/ directory to <JMETER_HOME>/bin/: 
    cp jmeter_files/daytrader7.jmx           <JMETER_HOME>/bin/
cp jmeter_files/daytrader7_mojarra.jmx   <JMETER_HOME>/bin/
Use daytrader7_mojarra.jmx only when the Liberty server is configured to use a Mojarra JSF implementation. For the standard Open Liberty JSF runtime, use daytrader7.jmx.

​
JMeter parameters

All configurable options are passed with the -J flag on the JMeter command line. Parameters not specified fall back to their defaults.
ParameterDefaultDescription
HOSTlocalhostHostname or IP address of the machine running the DayTrader application server.
PORT9082HTTP port of the DayTrader application server.
PROTOCOLhttpTransport protocol: http or https.
THREADS50Number of concurrent JMeter threads (virtual users).
RAMP0Ramp-up time in seconds for starting all threads. Set to the same value as THREADS for a smoother startup that avoids a thundering-herd effect at t=0.
DURATION180How long to run the test, in seconds. The standard benchmark window is 180.
MAXTHINKTIME0Maximum think time in milliseconds between requests per thread. 0 means no delay — threads issue requests as fast as the server responds.
STOCKS9999Total number of stocks in the database, minus one. The default assumes 10,000 stocks (s:0 – s:9999).
BOTUID0Lowest user ID number. Users are named uid:<n>.
TOPUID14999Highest user ID number. The default assumes 15,000 users (uid:0 – uid:14999).
WEBSOCKET_TIMEOUT60 (seconds)How long to keep the WS2 WebSocket connection open per thread before closing it.

​
Example commands

# Minimal run: 50 threads for 180 seconds against a local server
cd <JMETER_HOME>/bin
./jmeter -n -t daytrader7.jmx \
  -JHOST=myserver \
  -JPORT=9082 \
  -JPROTOCOL=http \
  -JDURATION=180
The -n flag runs JMeter in non-GUI (command-line) mode, which is required for benchmarking. Running in GUI mode adds significant overhead to the driver machine and will depress the throughput you can generate.

​
Enabling real-time output every 5 seconds

By default, JMeter summarises results at a 30-second interval. For a 180-second run this gives only six data points. To receive a summary every 5 seconds, edit <JMETER_HOME>/bin/jmeter.properties and set the following four properties: 
# Summariser — real-time output configuration
summariser.name=summary
summariser.interval=5
summariser.log=true
summariser.out=true
With summariser.out=true, each 5-second window prints a line to the console showing throughput (requests/sec), average response time, error count, and a cumulative summary. With summariser.log=true, the same output is also written to the JMeter log file.

​
WebSocket and HTTPS

The DayTrader test plans include two WebSocket samplers — WS1 (opening the WebSocket handshake) and WS2 (streaming live quote updates over the socket, held open for WEBSOCKET_TIMEOUT seconds). Because the WebSocket Samplers plugin does not support variable substitution for the host field, the -JPROTOCOL=https flag alone is not sufficient to switch WebSocket traffic to WSS. To enable encrypted WebSocket (WSS): Option A — Edit the .jmx file directly: Open daytrader7.jmx in a text editor and change the TLS property to true on both the WS1 and WS2 samplers. Option B — Use the JMeter GUI: Open daytrader7.jmx in the JMeter GUI (./jmeter -t daytrader7.jmx), navigate to the WS1 and WS2 WebSocket sampler elements in the test tree, and enable the TLS / WSS checkbox on each. Save the file before switching back to non-GUI mode for the actual run.
Performance numbers collected when using the TradeScenario servlet as the workload driver (URL: /daytrader/scenario) are artificially deflated compared to results obtained by driving the TradeApp servlet directly with a sophisticated form-filling load script like the JMeter test plans. The TradeScenario servlet runs on the application server itself, consuming CPU and thread resources that would normally be handled by the client or load driver. Use the JMeter test plans — which drive the TradeApp servlet — for all meaningful benchmark comparisons.

Build docs developers (and LLMs) love

Get started for freeTalk to us