Created
October 28, 2019 14:46
-
-
Save jkschneider/def8ecbd5c5c652246ebff26dfc7e53e to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
WebClient client = WebClient.builder() | |
.baseUrl("http://" + args[0]) | |
.build(); | |
Flux | |
.generate(AtomicLong::new, (state, sink) -> { | |
long i = state.getAndIncrement(); | |
sink.next(i); | |
return state; | |
}) | |
.limitRate(1) | |
.flatMap(n -> client.get().uri("/MYENDPOINT").exchange()) | |
.doOnNext(resp -> { | |
if (resp.statusCode().is2xxSuccessful()) | |
counter.increment(); | |
}) | |
.blockLast(); |
Hi, you may be interested in https://gatling.io/ instead of JMeter for a more complete product than a simple main program
Disclaimer: Gatling author here
Hi,
- indeed, Gatling uses a non blocking architecture, not a one-thread-per-virtual-user one + blocking IO.
- what you're doing is only realistic wrt server to server traffic where you share one global connection pool and SSLContext. If you want to simulate web traffic realistically, each virtual user must have its own connections and SSLSessions.
Regards
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@DarrenForsythe I like to think you don't need to make one and only one monitoring system choice inside an org, especially if you can convince those around you to stand up an OSS product for limited use like this while still using the expensive vendor option for production cases for as long as that is justifiable.