Repository navigation
Conversation
The jbang-launched wrk/wrk2@hyperfoil (hyperfoil-cli 0.30.0) ran on JAVA_HOME,
i.e. on the JDK under test, with the JVM defaults: G1, 8 MB initial heap, 1/4 of
RAM max. With 10K connections at 50K req/s wrk2 keeps ~1 GB of pre-allocated
sessions live (1,050,000 SessionImpl + HttpRequest + per-session maps), and every
young GC (every 8-25 s, 144-216 MB eden) pauses it for 60-110 ms. During the pause
no requests are sent; afterwards wrk2 sends the missed requests as a burst and,
with coordinated-omission correction, charges the stall to their latency. The
reported p99/p99.9 was the load generator's GC, not the server's: the server-side
request latency (kernel timestamps, arrival to response) had no burst while the
server was idle during each wrk2 pause.
Two new environment settings, documented next to JAVA_OPTS:
LOAD_GEN_JAVA JDK for the load generator (jbang --java), default 25
LOAD_GEN_JAVA_OPTS its JVM options, default -XX:+UseShenandoahGC -Xms5g -Xmx5g
applied to the warmup and the measured wrk/wrk2 launches through -R=<opt>.
Pinning the JDK also stops the load generator from running on the experimental
JDK under test, and makes the GC flag independent of that JDK (Oracle builds have
no Shenandoah; the JDK 25 that jbang resolves is Temurin).
Same server (4 carriers, 10K connections, 50K req/s, 30 ms mock), wrk2 numbers:
load generator GC rps p99 p99.9 max wrk2 GC pauses in 60 s
G1 default (JDK under test, 28) 48,528 55.3 - 163.6 4 x 67-108 ms
Epsilon (-Xms4g -Xmx16g) 49,974 36.96 55.84 96.47 none
ZGC (JDK 28, -Xmx16g) 49,959 381.7 - 530.6 none, but a 2.6 s major
collection with allocation stalls
Shenandoah (JDK 25, -Xms5g -Xmx5g) 49,975 36.18 88.60 147.85 16 x <= 0.2 ms
Shenandoah generational (JDK 25) 47,984 34.87 75.50 173.02 21 x <= 0.2 ms, rate missed
Shenandoah adds ~0.12 cores of GC threads on the load generator's CPUs (4 cycles
per minute) and the loops keep their cost; the generational mode cost the loops
~10 % more CPU and missed the rate, so the non-generational mode is the default.
Verified with -Xlog:gc* on both launches: "Version: 25.0.4.1+1-LTS", "Using
Shenandoah", heap 5G.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The jbang-launched
wrk/wrk2@hyperfoil(hyperfoil-cli 0.30.0) ran onJAVA_HOME, i.e. on the JDK under test, with JVM defaults (G1, 8 MB initial heap, 1/4 of RAM max). With 10K connections at 50K req/s wrk2 keeps ~1 GB of pre-allocated sessions live (1,050,000SessionImpl+HttpRequest+ per-session maps, fromjcmd GC.class_histogram), and every young GC (every 8-25 s, 144-216 MB eden) pauses it for 60-110 ms. During the pause no requests are sent; afterwards wrk2 sends the missed requests as a burst and, with coordinated-omission correction, charges the stall to their latency. The reported p99/p99.9 was the load generator's GC, not the server's: server-side latency from kernel timestamps (request arrival to response, bpftrace) showed no burst, and the server CPUs were idle during each wrk2 pause while only wrk2'sGC Thread#Nwere on CPU.This adds two environment settings, documented next to
JAVA_OPTS:LOAD_GEN_JAVA— JDK for the load generator (jbang --java), default25LOAD_GEN_JAVA_OPTS— its JVM options, default-XX:+UseShenandoahGC -Xms5g -Xmx5gapplied to the warmup and the measured wrk/wrk2 launches via
-R=<opt>. Pinning the JDK also stops the load generator from running on the experimental JDK under test and makes the GC flag independent of it (Oracle builds have no Shenandoah; the JDK 25 jbang resolves is Temurin 25.0.4.1).Same server for every row (4 carriers, 10K connections, fixed 50K req/s, 30 ms mock), wrk2-reported latency:
-Xms4g -Xmx16g)-Xmx16g)-Xms5g -Xmx5g)Shenandoah adds ~0.12 cores of GC threads on the load generator's CPUs (4 cycles per minute) while the event loops keep their cost; the generational mode cost the loops ~10 % more CPU and missed the rate, so the non-generational mode is the default.
Verified with
-Xlog:gc*on both launches of a run of this script:Version: 25.0.4.1+1-LTS,Using Shenandoah,Heap Min/Max Capacity: 5G;psshows~/.jbang/cache/jdks/25/bin/java -XX:+UseShenandoahGC -Xms5g -Xmx5g ... io.hyperfoil.cli.commands.Wrk2.