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.