JMeter中BeanShell Sampler传值REST API及分批压测数据异常排查

Hey there, let's work through your JMeter issues step by step—those duplicate employee IDs and misbehaving thread group execution are fixable with a few configuration tweaks!

Why You're Seeing Duplicate IDs & Misaligned Thread Execution #

First, let's break down the root causes:

• CSV Data Set Config Misconfiguration: By default, JMeter might be recycling CSV entries or not managing the "pointer" to your CSV file correctly across thread group stages. This leads to threads picking up the same ID multiple times.
• Ultimate Thread Group Setup: For your 20-test-data scenario, if the thread group stages aren't configured to run sequentially with the right delays, you won't get the "10 users first, then 10 after a pause" behavior you expect.
• BeanShell Sampler Logic: If your BeanShell code isn't correctly fetching the latest ${empid} variable, it might be outputting cached or duplicate values.

Step-by-Step Fixes #

1. Correct Your CSV Data Set Config Settings

This is the most critical part to ensure unique, sequential IDs:

• Open your CSV Data Set Config and verify these settings:
  • Filename: Double-check the path to your CSV file (absolute paths are safer for consistency).
  • Variable Names: Set this to empid (matches the ${empid} in your API path).
  • Recycle on EOF?: Set to False—this prevents JMeter from looping back to the start of the CSV once it hits the end.
  • Stop thread on EOF?: Set to True—threads will stop once there are no more IDs left to fetch (avoids errors when all IDs are used).
  • Shared Mode: Set to All threads—this ensures all threads across all stages of your Ultimate Thread Group share the same CSV pointer. So the first 1000 threads take the first 1000 IDs, then the next 3000 take the next 3000, no overlaps.
  • First line is column names: Tick this if your CSV has a header row (e.g., employeeid as the first line) to skip it.

2. Configure Ultimate Thread Group for Your Desired Flow

For both your 20-data test and full 20000-data scenario, set up the thread group stages properly:

• Stage 1 (1000 users / 10 users for testing):
  • Number of Threads: 1000 (or 10 for small tests)
  • Ramp-Up Time: 0 (to start all threads immediately for concurrent requests)
  • Hold Load For: 0 (threads stop as soon as they finish their request)
  • Delay Before Next Group: 20000-25000 (milliseconds, so 20-25 seconds of pause between stages)
• Stage 2 (3000 users / 10 users for testing):
  • Number of Threads: 3000 (or 10 for small tests)
  • Ramp-Up Time: 0
  • Hold Load For: 0

This setup ensures the first batch runs, waits the specified time, then the second batch runs—exactly what you need.

3. Fix BeanShell Sampler Output

Make sure your BeanShell code is correctly pulling the latest empid variable each time. Replace any existing code with this:

String currentEmpId = vars.get("empid");
log.info("Processing employee ID: " + currentEmpId);
// Or if you want to print directly to the Results Tree:
SampleResult.setResponseData("Current employee ID: " + currentEmpId, "UTF-8");

This ensures you're always fetching the fresh value from JMeter's variables, not a cached or duplicated value.

4. Validate with Small-Scale Tests First

Before running the full 20000-ID test:

• Use your 20-test-data CSV.
• Run the test and check the Results Tree: you should see the first 10 IDs used in the first stage, then the next 10 in the second stage, no duplicates.
• Verify the pause between stages works as expected (check timestamps in the Results Tree).

Final Checks #

• Ensure your CSV file has no blank lines or duplicate entries—clean data avoids unexpected behavior.
• If you're still seeing duplicates, add a Debug Sampler to your test plan. It will show you all variables for each thread, so you can confirm if ${empid} is being set correctly.

内容的提问来源于stack exchange，提问作者Ashu123