Practice: Plan and Design a Distributed Test

Time to put everything together. These exercises simulate real-world distributed testing scenarios you will encounter in your career. Work through them carefully -- interviewers love asking about distributed testing setup because it separates beginners from experienced testers.

Exercise 1: Infrastructure Planning

Your team needs to simulate 15,000 concurrent users for a banking application load test. The test script is medium complexity (SSL, 8 API calls per user flow, JSON extraction, CSV parameterization). You have access to AWS EC2. Plan the complete infrastructure.

1. Calculate the number of worker machines needed (assume 800 users per c5.2xlarge instance after safety margin)
2. Determine the JMeter thread count to set in the JMX file
3. List the jmeter.properties configuration changes needed on the master
4. Write the exact JMeter command to execute the distributed test
5. Calculate the expected bandwidth per worker (assume 4 req/sec per user, 25 KB average response)
6. Estimate the total cost for a 1-hour test run (c5.2xlarge is approximately $0.34/hour)

Exercise 1: Expected Answers

Workers needed: 15,000 / 800 = 18.75 -> 19 workers + 2 spares = 21 workers
Master: 1 machine (c5.2xlarge)
Total machines: 22

Thread count in JMX: 15,000 / 21 = 714 threads per worker
(Or use __P(threads,714) for flexibility)

jmeter.properties on master:
remote_hosts=10.0.1.1,10.0.1.2,...,10.0.1.21  (all 21 worker IPs)
server.rmi.localport=4000
server.rmi.ssl.disable=true  (test environment)

Command:
jmeter -n -t banking_load_test.jmx -r \
  -Gthreads=714 -Gduration=3600 \
  -l results.jtl -e -o html_report

Bandwidth per worker:
714 users x 4 req/sec x 25 KB = 71.4 MB/s (within 1 Gbps NIC capacity)

Total bandwidth hitting target:
71.4 MB/s x 21 workers = 1,499 MB/s = ~12 Gbps
(Target infrastructure must handle this!)

Cost: 22 machines x $0.34/hour x 1 hour = $7.48
(Plus a few dollars for data transfer)

Exercise 2: Troubleshooting Scenario

You have configured 5 worker machines and a master. When you run the test, 3 workers connect successfully but 2 fail with "Connection refused." jmeter-server IS running on both failing workers (you verified). What are the next 5 things you would check?

1. Verify the IP addresses in remote_hosts match the actual IPs of the failing workers (hostname -I on each)
2. Test port connectivity from master to the failing workers: nc -zv failing_worker_ip 1099
3. Check if jmeter-server is bound to the correct interface (netstat -tlnp | grep 1099 on the workers)
4. Verify firewalls on the failing workers allow incoming connections on port 1099 from the master IP
5. Check if the failing workers are on a different subnet or behind a NAT that the master cannot reach directly

Exercise 3: Cloud Platform Selection

Your manager asks you to recommend a distributed testing approach for the following scenario: The team has 3 QA engineers (no DevOps support), tests run twice per sprint (bi-weekly), target load is 8,000 concurrent users, existing test scripts are in JMeter JMX format, budget is $500/month, and the application runs on Azure.

Consider: Azure Load Testing (managed JMeter on Azure, integrates with Azure Monitor), BlazeMeter (managed JMeter, upload and run), self-managed JMeter on Azure VMs, or k6 Cloud (requires rewriting scripts in JavaScript). Write a one-paragraph recommendation with justification.

Exercise 4: CSV Data Distribution Strategy

You have a CSV file with 50,000 unique user credentials for your load test. You are using 10 JMeter workers. How do you distribute the CSV data so that no two workers use the same credentials simultaneously? Describe two approaches.

• Approach 1 -- Split the CSV: Divide users.csv into 10 files (users_1.csv through users_10.csv) with 5,000 records each. Deploy the appropriate file to each worker. Use a naming convention like users_${__machineName()}.csv or configure different file names per worker via JMeter properties.
• Approach 2 -- Single file with sharing mode: Deploy the complete 50,000-record CSV to all workers. In the CSV Data Set Config, set "Sharing mode" to "All threads" and use "Recycle on EOF: false." Each worker starts reading from the beginning, but since each worker has its own JVM, they will process in parallel. To avoid overlap, use JMeter __threadNum and __machineIP functions to calculate offset, or simply split the file (Approach 1 is more reliable).