SDKPerf Command Line Options

The complete list of command line options can be listed using the –hm (help more) command line option.

Common Options

The following are the more commonly used command line options:

CLI Option Description Example
Connection Options
‑cip=host Host (often IP:port) of the Solace message router ‑cip=
‑cu=user[@vpn] Client username and Message VPN name ‑cu=user01@vpn01
‑cp=string Client password ‑cp=secret
‑cc=int Number of client connections ‑cc=1
‑z=int Enables compression and specifies compression level ‑z=1
Subscription Options
-sql=list List of queue names from which clients will receive messages -sql=Q/1,Q/2
-stl=list List of topics that are applied as subscriptions (or mapped onto queues if used with –sql) -stl=T/a/b,T/c/d
-tqe=int Number of temporary queue endpoints to create per client. -tqe=1
Publishing Options
‑pql=list List of queue names to which messages will be published ‑pql=Q/1,Q/2
‑ptl=list List of topics to which messages will be published ‑ptl=T/a/b,T/c/d
‑mt=string Message type for published messages. {persistent | nonpersistent | direct }
(Default is generally “direct”)
‑mn=int Total number of messages to publish ‑mn=10000
‑mr=int Publishing rate in messages per second ‑mr=100
‑msa=list List of sizes in bytes for auto-generated binary attachment payloads ‑msa=100,200,500
General Options
-q Enable quite mode to suppress real time message rates -q
-md Dump all received messages to the screen as text. Do not use this with high message rates. -md
-hm Show the entire set of command line options -hm
-he Show some example command lines -he

JMS Options

JMS users will want to consider the following extra CLI options related to JNDI configuration.

CLI Option Description Example
‑jcf=string JMS connection factory. Default: /jms/cf/default ‑jcf=/JNDI/CF/demo
‑jndi Enable JNDI topic and queue lookups. By default queues and topics endpoints are created from the Session without JNDI lookup. ‑jndi

MQTT Options

MQTT users should consider the following extra CLI options related to MQTT QoS and Session clean.

CLI Option Description Example
‑mpq=int MQTT Publisher QoS. Sets the Quality of Service (QoS) of MQTT messages published.

Default: 0; Accepted Values: 0, 1 and 2.

‑msq=int MQTT Subscription QoS. Sets the Quality of Service (QoS) of subscriptions requested.

Default: 0, Accepted Values: 0, 1 and 2.

It is also possible to overload the default subscription QoS on a per subscription basis   by appending ‘qos=’ to your topic (e.g.’-stl=test_topicqos=1′)

‑mcs=bool MQTT flag indicating whether the session should be cleaned.

Default: 1 (true); Accepted values: 1 (true), 0 (false)


REST Messaging Options

REST users should consider the following extra CLI options.

CLI Option Description Example
‑spl=list Server port list. Define a comma-separated list of ports for

REST Consumers to connect to.


Performance and Latency Measurement

Latency measurement is controlled by several options. In general defaults are chosen such that latency measurement can be enabled by adding just -l to the command. However, it is often required to tune these parameters to match your environment. For high throughput tests, it is useful to enable Nagle’s algorithm to allow for greater network efficiency.

CLI Option Description Example
‑l Enable latency measurements (default is no latency). ‑l
‑psm Enable smooth publishers.  Enabled by default for latency testing. ‑psm
‑lg=int Latency granularity factor (default 0)

Controls bucket size. Bucket size increases by a factor of 2 for each increase of latency granularity. Current bucket size is printed in latency stats for reference.

‑lb=int Number of latency buckets (default 1024 buckets). Max is 4096. When you see N/A in the latency percentiles increasing number of buckets can help. -lb=4096
‑lp=2 Set the latency precision in significant digits after the decimal. Useful for sub-millisecond latency measurement ‑lp=2
‑lwu=sec Set latency warmup in seconds.  (default varies on a per tool basis, java based tools can generally benefit from a larger warmup time)  Messages arriving within the warmup are not counted in latency measurement. ‑lwu=10.0
‑nagle Enable Nagle’s algorithm (RFC 896) to allow higher tcp throughput. ‑nagle

Order Checking

With order checking enabled, published messages will have a Publisher-ID and a Message-ID encoded within the Solace message. We refer to the set of all messages with the same Publisher-ID as a “publisher stream”.

Consumers will decode this information during message processing and validate that Message-IDs from each publisher stream are received in sequential order. The first Message-ID received in each publisher stream will serve as the starting point for that stream.

CLI Option Description Example
‑oc Enable order checking ‑oc
‑pso=int Publisher stream offset. Clients will be assigned a Publisher-ID based on this offset. ‑pso=1
‑poo=int Publisher order offset. The initial Message-ID within each publisher stream will have this offset applied. ‑poo=100
‑upt Integrity data is encoded/decoded using properties rather the binary attachment. ‑upt

Note:  All clients will have the same Publisher-ID unless the “-pso” option is explicitly specified.

Sample Output

The following is sample output of the tool. This command will have a single client send one message on a topic and receive it on the same topic.

$ sdkperf_java -cip= HOST -cu=user01@default -ptl=T/a -mn=1 -msa=100 -mr=1 -stl=T/a

  • -cip and –cu identify the Solace message router, Message VPN and client username
  • -ptl and –stl identify the publish and subscribe topic
  • -mn and –mr specify to send a single message at a rate of 1 msg/sec
  • -msa specifies that the message should be 100 bytes in size.

When SDKPerf starts up, it will output environment information to the console.

CLASSPATH: :./lib/commons-cli-1.2.jar:./lib/commons-lang-2.6.jar:./lib/commons-logging-1.1.3.jar:./lib/nativetimer.jar:./lib/sol-common-*.jar:./lib/optional/log4j.jar:./lib/optional/
JAVA: /usr/bin/java
SOLACE_VM_ARGS: -Xms512m -Xmx1024m
Run Info: CPU usage currently disabled.
Client naming used:
    logging ID   = perf_client000001
    username     = user01
    vpn          = default
    client names = sdk generated.
> VM Name: Java HotSpot(TM) Server VM
Run Info: Using Java Nanosecond Timer for Timing
> Timing Package Clock Speed (Hz): 1000000000

In the above example, you can see the Java classpath, JRE location, and VM args. Additionally, SDKPerf will print information about the client so that it is easy to identify the client on the Solace message router.

Following this system information, SDKPerf will print a status line for each stage of the program.

> Getting ready to init clients
> Adding subscriptions if required
> Getting ready to start clients.
> Starting publish.
PUB MR(5s)=    0, SUB MR(5s)=    0, CPU=0
======>Main thread finish
> Running sdkperf shutdown...
Pausing -ped time to allow clients to finish recv messages (2000 ms)

Then, finally when it shuts down, it will print the summary stats outlining what was accomplished.

Aggregate Stats (Total # clients: 1):
Total Messages transmitted = 1
Computed publish rate (msg/sec) = 1.0
Total Messages received across all subscribers = 1
Messages received with discard indication = 0
Computed subscriber rate (msg/sec across all subscribers) = 1.0
CPU usage = 0%

At a minimum, SDKPerf will always print the number of messages sent and received and the computed message rate. It will print more detailed statistics as needed when the tool is used to measure things like latency, message order, message integrity, and so on.

Up Next: