Finding Limits Before Users Do

Load testing simulates real-world traffic to find performance limits, bottlenecks, and breaking points before they affect users. At Nexis Limited, we load test all SaaS products before major releases and regularly in production staging environments to ensure they handle expected traffic growth.

Types of Performance Tests

  • Load test: Simulate expected traffic levels to verify the system meets performance targets under normal conditions.
  • Stress test: Increase load beyond expected levels to find the breaking point and observe degradation behavior.
  • Spike test: Apply a sudden burst of traffic to test auto-scaling and system recovery.
  • Soak test: Apply moderate load for extended periods (hours or days) to find memory leaks, connection exhaustion, and other time-dependent issues.
  • Capacity test: Determine the maximum throughput the system can handle while meeting performance targets.

Test Scenario Design

Effective load tests simulate realistic user behavior, not synthetic single-endpoint tests:

  • Model user journeys — login, navigate, perform actions, logout — rather than hitting a single API endpoint repeatedly.
  • Use realistic data — different users, different request payloads, different query patterns.
  • Include think time — real users pause between actions. Tests without think time generate unrealistic concurrency.
  • Mix read and write operations in proportions that match production traffic.
  • Include heavy operations alongside light ones — report generation alongside simple CRUD.

Tools

  • k6: Modern load testing tool with JavaScript scripting. Our preferred tool for API and web application load testing. Excellent developer experience and CI/CD integration.
  • Locust: Python-based load testing with a web UI for monitoring. Good for teams familiar with Python.
  • JMeter: Mature Java-based tool with a GUI test builder. Comprehensive but heavy.
  • Artillery: Node.js-based load testing with YAML configuration. Quick to set up for simple scenarios.

Key Metrics

  • Response time (p50, p95, p99): Median, 95th percentile, and 99th percentile response times. p95 and p99 reveal tail latency that averages hide.
  • Throughput: Requests per second (RPS) the system handles.
  • Error rate: Percentage of requests that fail. Target: less than 0.1% under normal load.
  • Concurrent users: Number of simultaneous active users the system supports.
  • Resource utilization: CPU, memory, disk I/O, and network utilization during load. High utilization indicates approaching capacity.

Identifying Bottlenecks

When performance degrades under load, the bottleneck is usually one of:

  • Database: Slow queries, lock contention, or connection pool exhaustion. Check query latency and active connections.
  • Application CPU: CPU-intensive operations blocking request processing. Profile the application to find hot code paths.
  • Memory: Excessive memory usage causing garbage collection pauses or swapping.
  • Network: Bandwidth saturation or excessive network round trips between services.
  • External dependencies: Slow third-party APIs or services causing request queuing.

Load Testing in CI/CD

Integrate performance tests into your CI/CD pipeline:

  • Run abbreviated load tests on every PR merge to catch performance regressions.
  • Run full load test suites before production deployments.
  • Set performance budgets — fail the pipeline if p95 response time exceeds the target.
  • Compare results against baselines to detect regressions over time.

Conclusion

Load testing is not a one-time activity — it is an ongoing practice that validates your system can handle current and projected traffic. Design realistic test scenarios, measure the right metrics, and integrate performance testing into your development workflow.

Need help with performance engineering? Our team conducts load testing and performance optimization.