SDKPerf

SDKPerf is a tool for validating performance, checking configuration, and exploring features associated with your Solace PubSub+ message broker.

Versions

SDKPerf is available for the following programming languages and technologies.

SDKPerf Versions

SDKPerf for C sdkperf_c is a C++ application which uses the Solace C API. It is available on the following operating systems.
  • Linux 2.6 x86
  • Linux 2.6 x64
  • Solaris
  • Windows
SDKPerf for CS sdkperf_cs is a C# application that uses the Solace .NET API. It is available on Windows.
SDKPerf for Java & JMS sdkperf_java contains two client implementations in a single package: it supports both the Solace Java API and the Solace JMS API. The bin directory contains convenience scripts that make it clear which API is in use (for example, sdkperf_java and sdkperf_jms). Both sdkperf_java and sdkperf_jms will work on all platforms that the Solace APIs support.
SDKPerf for JavaScript sdkperf_js is a JavaScript application which uses the Solace JavaScript Web Messaging API. It is accessed through a simple web page which presents the various tool options in a graphical format.
SDKPerf for MQTT sdkperf_mqtt uses the Java SDKPerf platform and implements an MQTT client using the Paho Java API. It will work against all MQTT message brokers including the Solace PubSub+ message broker. sdkperf_mqtt will work on all platforms that have at least Java 1.6.
SDKPerf for REST sdkperf_rest uses the Java SDKPerf platform and implements an HTTP client that follows the Solace REST Messaging Protocol. It is a quick and easy way to explore the Solace REST Messaging Protocol. sdkperf_rest will work on all platforms that have at least Java 1.6.

Tool Dependencies

Often the correct functioning of certain SDKPerf command options requires associated configuration on the Solace PubSub+ message broker. You should keep this in mind as you explore various different tool command lines. The following are some specific dependencies.

  • SDKPerf JMS—All JMS connections to message brokers depend on being able to look up the connection factory from a JNDI store. So, at a minimum, you'll need to enable JNDI look-ups within a Message VPN and configure a connection factory.
  • SDKPerf REST—On the REST message consume side, SDKPerf REST acts as an HTTP server with the ability to correctly terminate Solace REST messaging connections and receive messages. For SDKPerf REST to receive messages, the message broker must be configured appropriately with a REST delivery point and a REST consumer within the Message VPN.

Many of the SDKPerf command line examples shown below assume this message broker configuration has been completed in order for the commands to work.

Quick Start

Give these commands a try if you just want to quickly get started with SDKPerf to send and receive messages. All the options and more examples are explained further in the sections that follow. Start with this one:

Sdkperf –cip=HOST -stl=a/topic –ptl=a/topic –mn=1 -msa=10 –md

That’s it! It publishes a ten byte message to topic a and subscribes to the same topic, displaying the messages it receives. Topic wildcards can be used for the subscription option. You can learn all about Solace topics in Topic Support and Syntax.

If you set up a new Message VPN and use a non-default username, use the -cu option, with –cp if you’re using a password. We didn’t use this before because SDKPerf uses the default username and JavaScript if you don’t specify one:

Sdkperf –cip=HOST -stl=a/topic –ptl=a/topic –mn=1 -msa=10 –md –cu USERNAME@MSGVPN

If you’re using Solace queues, provision your queue and substitute the -stl and -ptl options with the -sql and -pql options:

Sdkperf –cip=HOST -sql=a/durable/queue –ptl=a/durable/queue –mn=1 -msa=10 –md

That’s just a quick introduction. You can go further by learning more about SDKPerf options, architecture, and application flow, along with examples in the following sections.

Architecture

SDKPerf ArchitectureThe SDKPerf tools all share a common architecture across all the supported APIs and platforms. The following figure shows this architecture at a high level.

Because SDKPerf is a tool for testing messaging, internally it is modeled as a common core and a bunch of messaging clients implementations. The SDKPerf core platform exposes a client interface which it uses to generically interact with clients across any API. This allows for the SDKPerf tool to work in the same manner across all APIs and protocols it supports. This is depicted in the architecture figure where you can see that for each API or protocol there is a corresponding SDKPerf client implementation that makes use of the API protocol and implements SDKPerf's client interface. This allows the SDKPerf platform to code to focus on the performance and functional testing required in a client-agnostic way.

Application Flow

As a command line application SDKPerf will follow a specific application flow for a given invocation. On each invocation of SDKPerf it will do the following:

  1. Connect clients
  2. Add any required subscriptions and/or bind to endpoints
  3. Start publishing
  4. Wait until publishing is done
  5. Remove any subscriptions that were added
  6. Disconnect clients
  7. Cleanup and report stats

Note:  If the set of command line options used does not result in messages being published, the application will wait for SIGINT (Ctrl-C) instead of waiting until publishing has been completed.