13.4Concurrency Limit Testing

Every serverless provider enforces concurrency limits. Hitting the limit results in throttling (429 errors) that can cascade through your application:

// k6-concurrency-limit.js
import http from 'k6/http';
import { Counter, Rate } from 'k6/metrics';

const throttled = new Counter('throttled_requests');
const throttleRate = new Rate('throttle_rate');

export const options = {
  scenarios: {
    ramp_to_limit: {
      executor: 'ramping-arrival-rate',
      startRate: 10,
      timeUnit: '1s',
      preAllocatedVUs: 100,
      maxVUs: 2000,
      stages: [
        { duration: '1m', target: 50 },
        { duration: '1m', target: 100 },
        { duration: '1m', target: 200 },
        { duration: '1m', target: 500 },
        { duration: '1m', target: 1000 },  // likely exceeds limit
        { duration: '2m', target: 100 },   // cool down
      ],
    },
  },
};

export default function () {
  const res = http.get('https://api-gw.example.com/function');

  if (res.status === 429) {
    throttled.add(1);
    throttleRate.add(true);
  } else {
    throttleRate.add(false);
  }
}

What the Results Tell You

• At what request rate does throttling begin? This is your effective concurrency ceiling.
• How does the provider behave when throttled? Some providers queue requests; others reject immediately.
• What is the recovery time after a burst? How long until throttle rate returns to zero?
• Is reserved concurrency sufficient? If you have configured reserved concurrency, does it hold under load?