Load Testing Guide: k6, Artillery, and When to Performance Test

What is load testing?

Load testing is the practice of simulating realistic user traffic against an application to understand how it behaves under expected and peak conditions. Unlike functional testing, which checks whether features work correctly, load testing measures whether they perform acceptably when many users are doing things simultaneously.

A load test reveals what happens to response times, throughput, and error rates as concurrency increases. It answers questions like: can our checkout handle 500 simultaneous users? Will the API still respond in under 200ms when traffic doubles? How does the system behave when it approaches capacity?

Types of performance testing

Performance testing is an umbrella term covering several distinct test types:

• Load testing: simulates expected user volumes to verify the system meets performance targets under normal operating conditions
• Stress testing: pushes the system beyond its expected capacity to find its breaking point and understand failure behaviour
• Spike testing: simulates a sudden, sharp traffic increase, such as a viral post or a flash sale, to see how the system responds to rapid load changes
• Soak testing: runs sustained load over an extended period to detect memory leaks and performance degradation over time
• Scalability testing: gradually increases load to measure how performance changes as the system scales

When should you run load tests?

Performance testing is most valuable at specific points in the development lifecycle:

• Before a major release: to confirm the new version handles production traffic levels
• Before peak demand periods: Black Friday, product launches, and marketing campaigns
• After infrastructure changes: a new database, CDN configuration, or hosting tier
• After significant architectural changes: microservices migration, new caching layer, or API redesign
• When performance SLAs exist: if you have committed to customers on uptime and response time targets

Many teams wait until production failures to think about performance. The goal of load testing is to find those failures in a controlled environment first.

Load testing tools: k6, Artillery, and Gatling

k6

k6 (by Grafana Labs) has become the most popular modern load testing tool. Tests are written in JavaScript, making them accessible to frontend and backend engineers alike. k6 has excellent CI/CD integration, supports thresholds and checks, and produces clean metrics output. It is the tool we recommend for most web and API load testing projects.

Artillery

Artillery is a Node.js-based load testing tool that uses a YAML or JSON scenario format. It is well-suited to testing REST and GraphQL APIs and WebSocket connections, and integrates cleanly into GitHub Actions and other CI pipelines. Its scenario-based approach maps naturally to user journeys.

Gatling

Gatling is a JVM-based tool with a Scala DSL and excellent HTML reports. It is commonly used in Java-centric organisations and handles very high concurrency well. The learning curve is steeper than k6 or Artillery, but the reporting and simulation capabilities are comprehensive.

Apache JMeter

JMeter is the incumbent tool with decades of history. It remains in widespread use, particularly in enterprises with established QA toolchains. It is GUI-based, which some teams find easier to get started with, but this also makes version-controlling tests harder than code-based alternatives.

Key metrics to measure

A load test report is only useful if you know which numbers matter:

• Response time (p95, p99): the time taken for the server to respond. Focus on percentiles, not averages. A p99 of 3s means 1 in 100 requests takes 3 seconds or longer.
• Throughput (requests per second): the volume of requests your system processed, a measure of raw capacity
• Error rate: the percentage of requests that returned an error. Even a 0.1% error rate at scale represents thousands of failed user interactions.
• Concurrent users: the number of virtual users active simultaneously during the test
• Time to first byte (TTFB): useful for diagnosing server processing delays separately from network latency

Common performance bottlenecks

Load tests frequently surface the same categories of bottleneck:

• Database queries without indexes: fine at low volume, catastrophic under load
• N+1 query problems: ORM configurations that issue one query per record rather than one batched query
• Connection pool exhaustion: databases and external services with connection limits hit too early
• Synchronous external API calls: third-party services that become the bottleneck when called at scale
• Inefficient caching: cache misses that force expensive recomputation under load
• Insufficient server resources: CPU or memory limits hit before expected thresholds

Integrating load tests into CI/CD

Teams that treat load testing as a special occasion rarely do it consistently. The best approach is to integrate a short smoke-level performance test into your CI pipeline: a small load scenario that verifies key endpoints stay below defined thresholds on every deployment. Reserve the full load test suite for pre-release gates and scheduled runs against production mirrors.

k6 and Artillery both have GitHub Actions integrations that make this straightforward. Set threshold assertions in your test script so the pipeline fails automatically if p95 response time exceeds your target.

Need help setting up load testing? See our Performance Testing service or get in touch.

Related reading: Core Web Vitals: LCP, INP and CLS Explained