Sending Events to Event Hubs With JMeter

Azure Event Hubs is designed primarily to handle a large volume of messages per unit of time, to enable building high event volume processing systems.

When building such systems and when exploring event hubs features, it is interesting to be able to apply a relatively big load of events on topics.

JMeter is a flexible and mature load testing tool that can help us do load testing especially with the availability of pnopjp/jmeter-plugins containing an Azure Event Hub Sampler.

Full working example is available on Github as usual.

JMeter Benefits

JMeter is a powerful tool widely used for load testing applications to evaluate their performance under various conditions.

JMeter is designed for flexibility with its plugin architecture and its abstract building blocks can be composed together nicely, an indicative of its high maturity.

When working with Azure Event Hubs, dedicated samplers are available, enabling seamless integration for testing messaging workloads.

These samplers composed with various JMeter capabilities provide the capability to create dynamic messages within the tests, allowing us to simulate relevant business use cases with varied and dynamic payloads.

Furthermore, Azure Load Testing is built on the robust foundation of JMeter, leveraging its capabilities to deliver scalable, cloud-based load testing solutions.

With Azure Load Testing, we start by uploading a JMeter test plan then the service provides you compute resources for the load tests execution and enables you to integrate with Azure Metrics which can be included in test reports.

JMeter Concepts

To use JMeter effectively, we should first understand some of its basic concepts.

Test plan

A Test Plan is usually the root element in a JMeter test.

It encapsulates all the elements, settings, and logic required to execute a load test.

Settings include:

• Metadata
• User Defined Variables
• Toggle to run Thread Groups Consecutively

Test Plans are saved in .jmx files which are simply xml files.

This enables jmx files to be version controlled and modified via scripts easily.

User Defined Variables & Functions

User Defined Variables enable parameterization, replacing static values with dynamic placeholders that can be updated or reused across the test.

Variables can be defined directly in the test plan or in separate User Defined Variables elements.

Functions provide dynamism, allowing users to generate random data, fetch current timestamps, or execute custom logic during test execution.

Together, these features enhance test customization, ensuring realistic simulations and reducing maintenance efforts for repetitive or complex scenarios.

Thread Group

The Thread Group is the core component in JMeter for simulating virtual users and controlling the load generation.

It defines the number of threads (users), the ramp-up time (rate of thread creation), and the total number of test iterations or duration.

Each thread acts as an independent user executing a specified test logic. By using thread groups, we can simulate different user loads, traffic patterns, and peak conditions to analyze application performance.

Sampler

A Sampler is another key JMeter component responsible for sending specific types of requests to the target server.

JMeter provides a wide variety of samplers for protocols such as HTTP, FTP, JDBC, and way more.

Each sampler can be customized with parameters like endpoints, payloads, and authentication details.

Timer

A Timer in JMeter is used to introduce delays between requests generated by a sampler.

Timers can be applied globally or to specific elements within a Test Plan.

Various Timer types are available, such as Constant Timer, Gaussian Random Timer, and Uniform Random Timer, enabling us to model diverse traffic scenarios.

Listeners

Listeners in JMeter are elements used to collect and display test and request results.

They capture data such as response times, throughput, errors, and success rates, which can be visualized in various formats, including tables, graphs, and charts.

By offering both real-time and post-test reporting capabilities, listeners enables us to analyze testing outcomes.

Event Hubs Sample

Let’s dig into an example Test Plan available in Github.

Sending Events

The Test Plan defines 10 Thread Groups, each Thread Group contains an Azure Event Hubs Sampler configured to send the following message:

{
    "Id": "${__UUID}",
    "LocationId": "<LOCATION_ID>",
    "Content": "KABLAM"
}

In the message:

• We use the __UUID Function to generate a UUID dynamically
• LocationId contains an arbitrary id also used as a partition key value

We also defined a global Timer to control delay between requests.

Parameters

The Test plan defines some User Defined Variables used by the underlying Samplers and Thread Groups:

• EventHubNamespacePrimaryKey
• EventHubSharedAccessPolicyName
• EventHubNamespace
• MessagesCount
• TopicName

These parameters can be easily changed for all Samplers in a single location.

Note here that we used a Shared Access Policy to access the Event Hub for simplicity, it would have been better to use Entra Id authentication instead to avoid specifying secrets in the JMeter Test Plan

Listeners for Reporting

In this example, we defined two Listeners, View Results Tree and Summary Reports.

The View Results Tree is useful for showing each request sent and its response status:

The Summary Report is useful for viewing statistics regarding request and responses:

Running the Sample

If we run the sample JMeter Test Plan with a messages count of 5, 10 threads groups should be sending 5 events each, which is equal to 50 event in total.

And this is what we can observe in the incoming messages metric of the Event Hub:

Closing Thoughts

This post came to be while I was preparing a post on scaling event hubs consumers.

I was actually looking for a way to apply a consequent load of events and JMeter turned out fit for purpose 😁

You can learn more about JMeter in this cool video playlist.