handle more scenarios #1212
handle more scenarios #1212
Conversation
WalkthroughReworks CreateProductSimulation: replaces single open-load with a multi‑phase open workload (atOnce, ramp, constant, rampPerSec, sustained constant), increases rates/durations, simplifies product→inventory flow to a doIf-based conditional update, adjusts pauses/logging, relaxes mean SLA to 2.0s and adds failedRequests constraint. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor VU as Gatling VU
participant PS as Product Service
participant IS as Inventory Service
rect #EEF8FF
Note over VU: Multi‑phase open workload (atOnce → ramp → constant → rampPerSec → sustained)
end
VU->>PS: POST /products (createProduct)
VU-->>VU: log request time, short pause
VU->>PS: GET /products/{id} (getProduct)
VU-->>VU: store response in session
alt session contains inventoryResponseBody
rect #F7FFF0
VU->>IS: PUT /inventory/{productId} (updateInventory)
VU-->>VU: short fixed pause
end
end
VU->>PS: POST /orders (createOrder)
VU-->>VU: final pause
Note over VU,PS: Assertions evaluated (mean ≤ 2.0s, 95th pctl, failedRequests)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
gatling-tests/src/test/java/simulation/CreateProductSimulation.java(4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Run Unit & Integration Tests with jdk 21
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
gatling-tests/src/test/java/simulation/CreateProductSimulation.java(6 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Run Unit & Integration Tests with jdk 21
| .pause(200) // Reduced pause time from 500 to 200 ms | ||
| .exec(getProduct) | ||
| .pause(100) // Reduced pause time from 300 to 100 ms | ||
| .exec(getInventory) | ||
| .pause(100) // Reduced pause time | ||
| // Only attempt to update inventory when a valid | ||
| // inventory response body is present in the | ||
| // session. If it's missing or empty, skip update | ||
| // entirely to avoid runtime exceptions. | ||
| .doIf( | ||
| session -> | ||
| session.contains("inventoryResponseBody") | ||
| && session.getString( | ||
| "inventoryResponseBody") | ||
| != null | ||
| && !session.getString( | ||
| "inventoryResponseBody") | ||
| .trim() | ||
| .isEmpty()) | ||
| .then(exec(updateInventory)) | ||
| .pause(300) | ||
| .exec(createOrder)); |
There was a problem hiding this comment.
Fix pause units to match the intended millisecond delays
pause(long) in the Gatling Java DSL interprets the argument in seconds. The new pause(200), pause(100), and pause(300) calls therefore inject multi-minute sleeps (200 s, 100 s, 300 s) instead of the 200/100/300 ms noted in the comments, completely flattening scenario throughput. Please switch to the Duration overloads so the waits really are in milliseconds.
- .pause(200) // Reduced pause time from 500 to 200 ms
+ .pause(Duration.ofMillis(200)) // Reduced pause time from 500 to 200 ms
...
- .pause(100) // Reduced pause time from 300 to 100 ms
+ .pause(Duration.ofMillis(100)) // Reduced pause time from 300 to 100 ms
...
- .pause(300)
+ .pause(Duration.ofMillis(300))📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| .pause(200) // Reduced pause time from 500 to 200 ms | |
| .exec(getProduct) | |
| .pause(100) // Reduced pause time from 300 to 100 ms | |
| .exec(getInventory) | |
| .pause(100) // Reduced pause time | |
| // Only attempt to update inventory when a valid | |
| // inventory response body is present in the | |
| // session. If it's missing or empty, skip update | |
| // entirely to avoid runtime exceptions. | |
| .doIf( | |
| session -> | |
| session.contains("inventoryResponseBody") | |
| && session.getString( | |
| "inventoryResponseBody") | |
| != null | |
| && !session.getString( | |
| "inventoryResponseBody") | |
| .trim() | |
| .isEmpty()) | |
| .then(exec(updateInventory)) | |
| .pause(300) | |
| .exec(createOrder)); | |
| // Reduced pause time from 500 to 200 ms | |
| .pause(Duration.ofMillis(200)) | |
| .exec(getProduct) | |
| // Reduced pause time from 300 to 100 ms | |
| .pause(Duration.ofMillis(100)) | |
| .exec(getInventory) | |
| // Reduced pause time | |
| .pause(Duration.ofMillis(100)) | |
| // Only attempt to update inventory when a valid | |
| // inventory response body is present in the session. | |
| .doIf( | |
| session -> | |
| session.contains("inventoryResponseBody") | |
| && session.getString("inventoryResponseBody") != null | |
| && !session.getString("inventoryResponseBody") | |
| .trim() | |
| .isEmpty()) | |
| .then(exec(updateInventory)) | |
| // Restore intended 300 ms pause | |
| .pause(Duration.ofMillis(300)) | |
| .exec(createOrder)); |
🤖 Prompt for AI Agents
In gatling-tests/src/test/java/simulation/CreateProductSimulation.java around
lines 186 to 207, the Pause calls use pause(long) which interprets values as
seconds, causing multi-minute delays; change these to the Duration overloads
(e.g., Duration.ofMillis(200), Duration.ofMillis(100), Duration.ofMillis(300))
so the pauses are milliseconds as intended, and add/import java.time.Duration if
not already imported; keep the same relative placement of pauses and chain
calls.
| constantUsersPerSec(CONSTANT_USERS / 2) | ||
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 4)), | ||
|
|
||
| // Ramp up to peak load more quickly | ||
| rampUsersPerSec(CONSTANT_USERS / 2) | ||
| .to(CONSTANT_USERS) | ||
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 4)), | ||
|
|
||
| // Sustained peak load phase | ||
| constantUsersPerSec(CONSTANT_USERS) | ||
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 2)))) |
There was a problem hiding this comment.
Prevent zero-rate injection when halving constantUsers
Line 348 currently divides the user rate with integer math, so a legitimate override like -DconstantUsers=1 yields CONSTANT_USERS / 2 == 0. Gatling’s constantUsersPerSec(0) and rampUsersPerSec(0) throw an IllegalArgumentException at runtime, so any low-rate configuration now fails outright. Please keep these stages in the positive domain by switching to floating-point division (or otherwise guarding against zero).
- constantUsersPerSec(CONSTANT_USERS / 2)
+ constantUsersPerSec(CONSTANT_USERS / 2.0)
...
- rampUsersPerSec(CONSTANT_USERS / 2)
+ rampUsersPerSec(CONSTANT_USERS / 2.0)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| constantUsersPerSec(CONSTANT_USERS / 2) | |
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 4)), | |
| // Ramp up to peak load more quickly | |
| rampUsersPerSec(CONSTANT_USERS / 2) | |
| .to(CONSTANT_USERS) | |
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 4)), | |
| // Sustained peak load phase | |
| constantUsersPerSec(CONSTANT_USERS) | |
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 2)))) | |
| constantUsersPerSec(CONSTANT_USERS / 2.0) | |
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 4)), | |
| // Ramp up to peak load more quickly | |
| rampUsersPerSec(CONSTANT_USERS / 2.0) | |
| .to(CONSTANT_USERS) | |
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 4)), | |
| // Sustained peak load phase | |
| constantUsersPerSec(CONSTANT_USERS) | |
| .during(Duration.ofSeconds(TEST_DURATION_SECONDS / 2)))) |
🤖 Prompt for AI Agents
In gatling-tests/src/test/java/simulation/CreateProductSimulation.java around
lines 348 to 358, dividing CONSTANT_USERS by 2 uses integer division which
yields zero for small values (e.g. 1) and causes Gatling to throw
IllegalArgumentException; change the math to floating-point (e.g. divide by 2.0
or cast to double) or clamp the result to a positive minimum (Math.max(1.0,
CONSTANT_USERS / 2.0)) so constantUsersPerSec(...) and rampUsersPerSec(...)
never receive 0.
No description provided.