0

We have migrated/refactored one of our micro-service from request per thread model (sync) to Reactive (async). Development is complete and started stress testing the reactive service. We are looking for the help on how to perform the activity for reactive APIs

What we have done?

Our service makes HTTP call for an external service. During our stress test, we mocked the external service call. Instead of making a network call, we introduced delay using Thread.sleep() method and returning mock response in our service component(where we make actual HTTP call to the external service).

With this approach, we are observing our reactive service is getting crashed even with very small requests volume. Just to add, we follow similar approach while testing other sync services (request per thread model).

What can we try next?

halfer
  • 19,824
  • 17
  • 99
  • 186
Anoop Deshpande
  • 514
  • 1
  • 6
  • 23

2 Answers2

1

To have infrastructure closer to what will be live environment, I would suggest to run separate mock server, preferably on separate machine, so it will not steal resources from your service.

You can do it easily with wiremock - see running as standalone page.

When you run wiremock as proxy, you can record and playback real requests from your service.

To make this mock more real, you can add delay for mock responses - it will simulate external service "processing time".

Bartek Jablonski
  • 2,649
  • 24
  • 32
  • One thing to be careful about with wiremock and reactive clients in stress tests - wiremock uses jetty underneath (thread per request) and may not be able to cope with the load, especially if you add some sofisticated logic or use handlbars templates extensively (even thou wiremock has a cache for them). – Alex K. Apr 26 '21 at 23:18
0

reactive services have a very small thread pool which is optimized to be utilized at 100%.

If you introduce something blocking like Thread.sleep() you are basically removing this ability. What makes reactive, "reactive" is its ability to switch execution threads if something is blocking.

Thread.sleep() holds the thread where it is, and it cant switch to doing something else, basically crippling its entire functionality.

You should never Thread.sleep() in a reactive application, unless you are using OnSubscribe and placing each call on a separate scheduler, which in turn sort of makes your reactive application "non-reactive" and instead fallbacks to default standard servlet application behavior.

Toerktumlare
  • 12,548
  • 3
  • 35
  • 54
  • Yes, I agree that using of `Thread.sleep()` takes us back to blocking model. For the `reactive apis` how can we perform stress testing? What is the standard approach or do we have any framework out there to help us with? – Anoop Deshpande Apr 23 '21 at 06:59
  • I gave you an answer to why you are seeing bad performance. That was a direct question with a direct answer. How you should do your testing on the other hand is opinionated, and there are a 1000 different approaches and there is no straight answer. – Toerktumlare Apr 23 '21 at 08:26