Is it possible to load test asynchronous services (Message consumption from Azure Service Bus Topic and storage in DB ) using k6?

How can we perform load testing of a microservice which is consuming the json message from Azure service bus topic and then storing the details in DB. Is there a way we can write an end to end test in k6 for this scenario?

Putting some more information below related to the service just in case

How can we measure the time the microservice takes to store the message in DB? There is no direct end point to consume the message from topic rather the microservice is listening to the topic and then performing the action.

Hi @praveenaset, welcome to the community forum :tada: !

Am I getting correct that you sent a request/message and you want to measure when a worker finishes working on it.

But there is nothing an outside service/application (k6) can observe to measure it.

If that is the case - no k6 can’t be used for that.

I do expect that:

There actually is some change - likely some other API changes what it returns. You can poll that API and use a custom metric to measure it.

Irregardless of load testing I would recommend instrumenting and measure this in some way:

  • official azure docs on service bus insights
  • official azure docs on monitoring with grafana
  • grafana docs on azure monitor

Hope this was helpful

I apologize if the question is not clear.

I am sending the message to the topic as http request and the message processor microservice is reading the topic and picking that message and storing in DB.

I wanted to know if we can leverage k6 to measure the time from the moment message is consumed from Topic by the microservice to its storage in DB ? sharing the flow chart (image) for more clarity.

Thanks
Praveen

Seems like the original explanation was sufficient as I understood more or less what you described.

The answers remain the same - k6 (and any other tool) will need to have something to check that a message has arrived in the DB. Whether this will be waiting on a websocket for example, grpc or will be doing http requests every second to see it went to the DB. Somehow the tool will need to find out the message got there - and that depends on your API and application.

The alternative(or even “in addition”) as mentioned above is to have something measuring this all the time. Monitoring how long messages take to get to the DB and have k6 generate traffic and then look at what the monitor shows. Some links were provided above.

Hope this helps you!

Thanks for the explanation!