Biju Kunjummen

Yes, mis-statement on my part Simon.

Sorry Vitaly, I am likely misunderstanding you here.

Just to be clear, gatling(https://gatling.io/) is an external tool, it has nothing to do with the Spring Boot 2 - all it does is pump requests to your endpoint and waits for 200 to come back and aggregate this information.

Additionally, the code that you have pointed out is the micrometer configuration (https://github.com/micrometer-metrics/micrometer), that is indeed built into the framework and is internal to the server but that is not the number that I published. micrometer does collaborate the numbers seen via gatling though.

It is absolutely possible that I am missing something, why not try the codebase - start it up and see for yourself if you are seeing a different behavior.

AsyncRestTemplate will make a difference but the objective as stated was to compare blocking semantics in Boot 1 with non-blocking semantics of Boot 2. I deliberately chose a scenario that is tilted towards Boot 2 and I have stated that explicitly too.

I am not sure what you mean by total latency of request, that is exactly what is being measured from the gatling perspective. The 300 ms number is coming from gatlings report, and gatling waits for the entire request to be completed before measuring the time - so no, it is not just for the async response, it is for the end to end response.

Hi Anton, Nice, I like your approach. There is actually a simpler approach that Spring Cloud Pipelines uses - https://github.com/spring-cloud/spring-cloud-pipelines/blob/master/concourse/tasks/generate-settings.sh#L15, this approach may actually be simpler. What it does is it caches gradle and maven folders and then simply links ~/.m2 and ~/.gradle folder to these cached folders, this way there is no other change required.

It was run on my Macbook Pro Brandon. 16G RAM, 8 core(2.8 GHz). I did not run the test on containers.

Yes, it is Thai Dang Vu , that is exactly how the author Jon Schneider also characterises it

Interesting, thanks Juan. I have personally not used hierarchies yet, will explore what you have said.

Hi Mitch, looks like the formatting of code is bad once more, can you please check on what could be going wrong

You can have a little more control over when the command is executed using Observable version - if you use .observe() method then you have a hot observable that executes immediately and is similar to the one that you get via HystrixCommand, but on the other hand if you use .toObservable() you get back a cold observable and you can choose not to consume it or ignore the command.

Thanks @Nicolas for pointing out the issue in the article republished from my blog site, I was not aware of it until I happened to see your comment today. @RickRoss, I used to get a link to a draft earlier before it was published, anyway to enable such a feature again in Dzone, this way the author can quickly check it and ensure any corrections are propagated back before being published. BTB, one of the "likes" is from me, I did it unfortunately from the listing in the articles page without browsing through the actual content and assumed that it would exactly match what I have in the blog site here .